> > Arguably, best place to optimize a constant in this case would still be
> > compile time.
>
> How exactly would you want the C# compiler to optimize this? As Barry
> said, the boxed int must live on the heap anyway, so the only
> "optimization" you can get is by sharing that heap object between
> different boc instructions. Then, however, there is the question of
> the lifetime of the box. Should it be shared and kept alive on method
> level? On class level? Application-wide? How many boxed integers (and
> other primitives) should be kept alive at a single time?
>
> And, the most important question, would it be worth the effort?
> Allocating a heap object is negligible in nearly all scenarios anyway;
> it definitely is in calls to Console.WriteLine.
>
> All these are questions the JIT compiler can give better answers to
> because it knows more about the actual execution of the code than the
> C# compiler does. And in addition, it wouldn't be economic to add
> optimzers to single .NET language compilers anyway; optimizations
> built into the JIT compiler automatically apply to any .NET code.
While I agree that the JIT is a good candidate for optimizations,
let's not overreact on the scale the JIT can actually do something: its time
is limited and therefore its knowledge of what it deals with. The JIT should
be a central system which knows everything but that's not realistic: it should
be given hints and optimized code so it can do its job better. So ultimately,
a compiler working for a JIT-based runtime, should optimize the code in such a
way that the JIT can make better decisions, in less time so it knows more.
However I don't think it will ever reach the point where it knows everything.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
