Release build not optimizing

[Jon Skeet [C# MVP]]

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.

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?

Yes.

 

[Willy Denoyette [MVP]]

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.

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.

 

[tjmadden1128]

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.

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

 

[Jon Skeet [C# MVP]]

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?

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

 

[Marc Gravell]

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

 

[Brett Romero]

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.

 

[Marc Gravell]

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

 

[Brett Romero]

A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?

 

[Brett Romero]

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]

A little off topic but why do release builds still generate PDB files
(although smaller than their debug counterparts)?

 

[Brett Romero]

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)?

 

[Brett Romero]

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.

 

[Ben Voigt [C++ MVP]]

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)?

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.

 

[Jon Skeet [C# MVP]]

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)?

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.

 

[Brett Romero]

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.

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.

 

[Brett Romero]

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.

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