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

[Andreas Nahr]

----- Original Message ----- 
From: "Ben Maurer" <bmaurer at ximian.com>
To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza" 
<miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
Sent: Friday, July 29, 2005 1:15 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions


> 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:

If we merge everything into a single file we probably have about 20 consts, 
each about 50 chars long.
Depending whether this is saved in the assembly as unicode or ascii (which i 
don't know) this should be 1-2kb just for the strings in the string heap.

>
> 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.

All the fields are NEVER used at runtime, so I hope they do not get loaded 
at all ;)
There is no access to these fields. They are only used at compile time, but 
not at runtime.

>
>> 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.

There are obfuscators out there that you can use, however that is not 
exactly what I mean:

Look at the example:

const string a = "Hello ";
const string b = "World";

[SomeStringAttribute (a+b)]
private void Out () { }

If I understand thing right we end up having the following strings in the 
assembly:
"Hello World" (as part of the attribute)
"Hello ", "World" (in our case these use their own class)

However after compilation the strings "Hello " and "World" are never used 
anywhere at runtime, so we could delete them.
AFAIK not even the MS compiler is able to do that ;)