Release build not optimizing

  • Thread starter Thread starter Brett Romero
  • Start date Start date
Brett Romero said:
Ok, yes - I see the difference. The method body has been optimized.
Since that is the case, why isn't the optimized EXE footprint
smaller? Bytes have been removed.
Click to expand...

If you declare a type with only a single byte field, that will take the
same amount of space as a type with a single short field. It's the same
kind of thing here. There are certain alignments which are followed, so
there's "wasted" space - you've just got a bit more wasted space in the
file for the release version than the debug version.
The manifest is stored in the EXE
and that's where ILDASM gets it's info from right?
Click to expand...

Yes.
 
Jon Skeet said:
Would it be illegal to do so though, as an academic question? I know
the method would still be available to reflection, but I'm not sure
whether that really counts in terms of correctness.
Click to expand...

Good question, I don't think it should be illegal to remove the redundant
method, granted it would break the code that uses reflection to call
"private" methods that are completely optimized away, but as you said this
doesn't count in terms of correctness.
The point is, what would we gain in terms of performance (load time, code
generation time and run-time)? I guess nothing, really.

Willy.
 
Good question, I don't think it should be illegal to remove the redundant
method, granted it would break the code that uses reflection to call
"private" methods that are completely optimized away, but as you said this
doesn't count in terms of correctness.
The point is, what would we gain in terms of performance (load time, code
generation time and run-time)? I guess nothing, really.

Willy.
Click to expand...

I don't understand. If you have a private method, and there are no
calls to it from inside the class, why would it make a difference to
reflection? Can you access private methods in an instance of a class
with reflection (I haven't used it much, so I don't know)? Would this
break encapsulation?

Tim
 
I don't understand. If you have a private method, and there are no
calls to it from inside the class, why would it make a difference to
reflection? Can you access private methods in an instance of a class
with reflection (I haven't used it much, so I don't know)? Would this
break encapsulation?
Click to expand...

Yes, you can get to it if you've got full trust.
Yes, it breaks encapsulation.

In fact, you can do some really scary things - like changing string
the contents of string literals...

Reflection of non-public members should be regarded as a very
dangerous powertool. Occasionally handy, but use with extreme caution.

Jon
 
Just as an aside... a number of System.ComponentModel features rely on
using (public or private, it doesn't matter) methods via reflection;
for instance void Reset{propertyname}() and bool
ShouldSerialize{propertyname}() - and of course it would be very
unlikely to ever call these methods yourself manually (from your
assembly), hence they would show as unused if you scanned for them.

This is just intended as an illustration that some core parts of the
existing codebase have come to depend on such [ab]use, so I wouldn't
imagine it changing any time soon.

Marc
 
What would cause debug and release EXEs on other projects to be
different sizes? It seems from the bogus method experiment that the
file size should not change.
 
file size should not change.

*might* not change. Alignment is funny like that. Also, some code has
#if sections which might omit chunks for different compiles. I can't
remember (and I really should...) what the compiler does with
Debug.WriteLine etc... they might get skipped? [I really should know
that off the top of my head]. You might have more/less code that is
suitable for compiler-optimisation (rather than JIT-optimisation).
Small asemblies might be less prone to changing than large assemblies
(just the cumulative effect of lots of small alignments).

etc.

Marc
 
A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?
 
What would cause debug and release EXEs on other projects to be
different sizes? It seems from the bogus method experiment that the
file size should not change.
 
A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?
 
Please ignore the previous redundant posts. I didn't flip the page in
Google Groups to notice they were posting.

The other projects do have precompilers and Debug.WriteLine() entries
whereas this one doesn't. That explains how they differ in file size.

I did an experiment by adding Debug.WriteLine() entries into the test
methods. The debug EXE is larger for 4KB. Thanks!

I'm still curious on this though:
A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?
 
What would cause debug and release EXEs on other projects to be
different sizes? It seems from the bogus method experiment that the
file size should not change.
 
Brett Romero said:
Please ignore the previous redundant posts. I didn't flip the page in
Google Groups to notice they were posting.

The other projects do have precompilers and Debug.WriteLine() entries
whereas this one doesn't. That explains how they differ in file size.

I did an experiment by adding Debug.WriteLine() entries into the test
methods. The debug EXE is larger for 4KB. Thanks!

I'm still curious on this though:
A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?
Click to expand...

Because most people want PDB files of their release builds.

The reason for that is that while you don't install the pdb with your
program, if bring a crash dump back to the developer, the pdb is needed to
analyze it.
 
I'm still curious on this though:
A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?
Click to expand...

I didn't *think* that they did by default, although I could well be
wrong, and whatever settings I happen to have now may not be default
ones so I can't easily check.

However, don't forget that you *can* attach to a release build of
managed code - it won't be as easy to debug, but you can still do it.
 
Because most people want PDB files of their release builds.

The reason for that is that while you don't install the pdb with your
program, if bring a crash dump back to the developer, the pdb is needed to
analyze it.
Click to expand...

Do you have any links on that process? When I run a release build in
the IDE, it doesn't allow me to do anything useful. I get the "no
source code available" message.
 
I didn't *think* that they did by default, although I could well be
wrong, and whatever settings I happen to have now may not be default
ones so I can't easily check.

However, don't forget that you *can* attach to a release build of
managed code - it won't be as easy to debug, but you can still do it.
Click to expand...

Yes - that is right. I was wondering about getting additional info
from release PDBs with a crash dump, as Ben had mentioned. Thanks.
 
Back
Top