Re: Redundant IL generated by the compiler

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I agree in doing things right the first time to if you wanted this done
'correctly' in IL, perhaps you should have coded it that way as you knew that
you didnt need the s variable. If you remove the first assignment to s and
put the readline call as the param to the parse call then the IL is removed.
The compiler is doing what you told it to do.
So if you are that concerned with doing it right first time and not wasting
time compiling those statements and storing them, you need to optimise your
code. The compiler cant as you could still attach debuigging components and
expect to see a value in the field s.


--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com


"Anthony Paul" wrote:

I agree with you that the emphasis should be on the JIT when it comes
to optimization; however, I'm a firm believer of doing things right the
first time around. I've read another thread (in which you've been
involved) that was rather interesting regarding this very subject and
am aware that perhaps the MSIL shouldn't be highly optimized (ie. loop
unrolling) because the JIT would do a better job of it seeing that it's
aware of the underlying platform. I can see that now and though I'm not
in the position to agree or disagree I see that there may be undesired
consequences and that's good enough for me. However, in this specific
case I see redundancy in the code that has nothing to do with
optimization... it's just redundant, dead code that does nothing but
contribute to bloat. It's a minor thing really, maybe I'm just being
anal about it but this is probably due to my having learned how to
program in a time when one would drool all over 32K of memory, 1 mhz
processors were the "bomb", and data was stored on tape or floppies.
Ahhh, the good ol' days!! :D

Cheers!

Anthony

p.s. Oh, and shame on you! The C# compiler team should NEVER make any
assumptions! :D

If the C# compiler team knows (for certain) that the JIT will optimise
away those statements when there is no debugger attached, what's the
downside of making it easier to debug even in release mode?

I would imagine that it makes for simpler compiler code - and given
that you'll end up with multiple high level language compilers but only
one JIT, I'd rather the optimisation went into the JIT than the high
level language compilers.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


.

Relevant Pages

  • Re: Web service slow on first call? In memory or cache option for web service?
    ... The JIT can occur more than just the first time the webservice is hit ... The JIT compiler only compiles the code into memory and ... Your worker process is likely configured ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: Branch prediction
    ... > the first time the branch was encountered. ... Are CPUs able ... trying to hand-assemble some code to run faster than the compiler. ... very effective for tight inner loops.) ...
    (freebsd-hackers)
  • Re: Delphi seems to have gone nuts...
    ... one I'm editing and one which is being compiled. ... and ALL of my working source code is in that folder. ... > compiler is always just using the existing DCU file, ... Not the first time. ...
    (alt.comp.lang.borland-delphi)
  • Re: Getter performance
    ... it uses the JIT compiler which optimizes the code ... int a = myObject.getA; ... Which also, if I understand things correctly, means that the first time you do almost anything in a Java program, it's much slower than the Nth time. ...
    (comp.lang.java.programmer)
  • Re: another frustrating learner question, CLOS
    ... first time you read of of his texts, but if this is the case, I guess I ... We can differ on our reasoning, and we can even differ on the ... Well, gosh, I'm a Unix guy, cutting my teeth on BSD. ... OS without the compiler. ...
    (comp.lang.lisp)