tags:

views:

59

answers:

2

This question is more of theoretical nature than of practical use.

I know that there are several programs to find unused code, but this question is a little bit different then that.

Would it be possible to find unused code and resources during or after the build and remove it? I've several 'generic' libraries which are shared across many projects, and each project is only using a part of those libraries (overlapping and may change in the future, so no direct refactoring possible and I don't feel like breaking those further down). My idea was to remove these unused parts to keep the resulting files small.

So, what are my odds to accomplish this?

Edit: There's a tool from the Mono-Framework available called Mono.Linker, which does exactly what I was looking (in combination with mkbundle). Unfortunately, the build seems to be broken due to changes in Mono.Cecil. I'll see if I can fix that.

+2  A: 

It's one of those very nice features of the JIT compiler: it only compiles code that is actually executed. Dead code in the DLL will never be used. It won't even be loaded in memory. You can shave, say, 10 KB from the VM size of your program. That saves 0.0005% on a 32-bit machine.

Don't bother.

Hans Passant
Actually, removal of dead code is sometimes useful. It can save on the *working set* (far more important than VM size) and distribution size, sometimes significantly.
Stephen Cleary
Working set is what's in RAM. Dead code never gets into RAM.
Hans Passant
Images are mapped into memory on a page-by-page basis. Each page mapped may include some amount of dead (IL) code. There won't be any dead (native) code, but the dead (IL) code is still read from disk and taking up working set space at least for a while.
Stephen Cleary
@Stephen: If that transient paging of unused code is significant enough to be a problem (ie. removing it makes a noticeable difference) then you have bigger problems.
Richard
@Richard: In my own situation, I have one particular library that is several megabytes in size. My 17KB app only uses a handful of classes in it - literally, 1-2%. I don't know if removing the dead code would make a "noticeable" difference, but it would at least do *something*. If nothing else, it would greatly reduce the redistributable size. :)
Stephen Cleary
@Stephen: code in a reusable library your application doesn't call doesn't make it dead code. Only code that cannot be called would fit that description. In any case I doubt there is much of that library being paged in, something like [VMMap](http://technet.microsoft.com/en-gb/sysinternals/dd535533.aspx) might tell you.
Richard
@Richard: I'm using the term "dead code" with the common meaning (as in, "dead code elimination" being one of the traditional native compiler optimizations). Even using your definition ("can't" be called instead of "isn't" called), I'm using ILMerge to make the library internal, so it can't be called (not considering Reflection over internals as a valid approach). But I'm not worried about a minor optimization for my little app - it's not worth my time/money to research it. However, if this was a Silverlight app, then that would be a very different story.
Stephen Cleary
+2  A: 

All commercial obfuscators I'm aware of will optionally remove unused code. I'm not aware of a free solution (all of their free trials do not include this functionality).

Stephen Cleary
<strike>-1, not in .NET they wont.... </strike> (+1, I read it wrong, I thought you said compilers, and not optimizers)
leppie
Ha, I meant "obfuscators" anyway! Fixed...
Stephen Cleary