[Mono-devel-list] [PATCH] Profile 2.0 assembly versions

[Ben Maurer]

On Fri, 2005-07-29 at 00:42 +0200, Andreas Nahr wrote:
> Yes - it would make a lot of sense to put them into a single file. However 
> it would come at a cost of up to 2kb of size added to EACH assembly that 
> uses Consts.

Maybe the *FILE* will be 2 kb, but the metadata added probably won't be.
To add a class with a single const we'd need to add:

1) a entry in the classes table
2) an entry in the fields table
3) a constant string in the strings heap.

At runtime, the only datastructure that will ever be allocated due to
this class is the hashtable that goes from Namespace/Class -> class
field. I'm not even sure if that gets created for private classes, I'd
have to dig into the code.

The fields and string heap data gets loaded lazily on the first access.

> In fact I think we could do something really clever to our compiler here, 
> that would also benefit for a lot of other cases.
> AFAIK the compiler can already eliminate dead code. I would propose a step 
> that allows the compiler to scan for dead code again AFTER constants are 
> resolved. This way the compiler would be able to completely eliminate the 
> Consts Class after compiling. This would also add lots of added value to 
> other applications. It's quite common to use private consts and especially 
> enums to structure the code and make it more readable. With the proposed 
> compiler function all of these things could be thrown out at compile-time, 
> which could help a lot of applications to get smaller.

A cecil based il-to-il optimizer could do that in the future. Of course,
if you really want to look at "how can we make teh metadata smaller" we
could do a simple obfuscator -- we could rename private / internal
methods/classes to have small names, etc.

-- Ben