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

[Kornél Pál]

I agree with you. I don't like the fact that the compiler embeds private
constants altough they are not used at all. Furthermore in a lot of cases
private enumerations are not required at runtime.

I think we don't need any special obfuscator or Cecil tool we just should
add two compiler options to mcs:
- do not add private (invisible outside the assembly) constants
- do not add enums that are not referenced by type

None of them should be default because constants can be accessed using
reflection that may be required and field names of enums may be used in
Parse or ToString.

Kornél

----- Original Message -----
From: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
To: "Ben Maurer" <bmaurer at ximian.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 9:32 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions


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