Timeline for Dynamic, generic property "assignator"
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 12, 2015 at 0:39 | comment | added | Oguz Ozgul | It depends on what kind of project that is, and what kind of load will it face. Apart from that, in my opinion, everyone should keep track of the performance of their code. This is something you are going to need when you start selling your software to enterprises with millions of customers. Consider the difference of the benchmark in my answer. The original code, proportionally, requires 6 cpu for a task which is accomplished by CodeDom by only one. | |
| Dec 11, 2015 at 23:15 | comment | added | moarboilerplate | @OguzOzgul you might be right about the expression being faster than reflection once it's compiled. That said 1) there's still the overhead of compiling up front and 2) the expression approach is way more complicated. The same could be said for the CodeDom approach--is the extra complexity really necessary? | |
| Dec 11, 2015 at 23:03 | comment | added | Oguz Ozgul | Linq compiled expressions will also beat reflection I think, reflection cannot be as fast as to execute 30 million (3 property assignment x 10 million iterations) even if you cache the property info (The benchmark metrics will say the last word of course) | |
| Dec 11, 2015 at 23:01 | comment | added | Oguz Ozgul | I am going to benchmark a reflection only solution as well, but no other solutions can ever beat the CodeDom approach since it is pure compiled code, in the CodeDom case, you are invoking a method directly, not through delegates nor you are iterating dictionaries to find the cached compiled expression | |
| Dec 11, 2015 at 22:11 | history | answered | moarboilerplate | CC BY-SA 3.0 |