StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Modifying the size of the compiled code, either pre or post JIT, can have an impact on performance.</p> <p>For example, increasing the amount of executable code can cause extra cache misses, or use up more Virtual Memory. Both of those cases can slowdown execution of the program.</p> <p>Also, increasing the number of named types present in an assembly can slow down the runtime. If the runtime has to examine larger data structures to resolve type names, then resolving type names and performing JIT compilation can take longer.</p> <p>Finally, if their are more types to JIT, then the CLR can end up spending a larger fraction of its time generating code.</p> <p>You would need to run tests to be sure, but my guess is that doing what you are talking about would have a net-negative effect. </p> <p>The CLR is pretty smart about the generic code that it generates, though. Different reference type instatiations of generic methods end up using most of the same native method body, except for the parts that require loading type tokens. Value type instatiations, however, end up getting their own unique native method bodies.</p> <p>This generally provides good performance. It balances the performance impact of code bloat against the performance impact of extra boxing.</p> <p>It certainly is possible for you to construct workloads where the CLR design would lead to non-optimal performance. Those cases, however, seem pretty pathological to me. I'm willing to bet that with most real code, you would get better perf by just using CLR generics directly.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload