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

[Andreas Nahr]

Kornel already said that: its just a suggestion. And as you said it will be 
near to impossible to measure performance gains, because you would need to 
instrument the OS itself. However one thing is clear, you could save 
assembly size (and with it OS disc cache and so on).
And it would allow us to make a few things simpler on the management side 
(like combining all Const.cs files) without having to worry about that 
having any negative effect (in fact I don't like the idea that code that 
uses magic numbers might be better, because it delivers more performance or 
needs less memory).
As I already said for our consts this would add about 2,5kb per assembly 
(Unicode + Fieldnames + Class) just for the consts.cs file (Ben - NONE of 
the fields are ever used again). And there might be some other places where 
this might also make sense.

An example showing (all?) possible cases:

using System;
using System.Reflection;

[assembly: AssemblyVersion (Consts.version)]

public class Class1
{
 [Obsolete(Consts.obsolete + Consts.constructor)]
 public Class1()
 {
  Console.WriteLine (Consts.obsolete + Consts.constructor);
 }
}

internal class Consts
{
 internal const string obsolete = "This member is obsolete: ";
 internal const string constructor = "Class1 Constructor";

 public const string version = "2.0.0.0";

 internal const string someunused = "some completely unused const";
}

The class Consts is entirely useless after compiling and it could be 
completely left out. None of its fields are used and none of the strings are 
shared.
In fact the "This member is obsolete: ""Class1 Constructor" will be stored 
3! times in the resulting assembly, which might surprise quite some people.

By the way - i found a bug in the mcs compiler in the process:
If you change the public version const to internal the compiler refuses to 
compile the class, obviously it should do it (csc works correctly)

Greets
Andreas

> On Fri, 2005-07-29 at 09:32 +0200, Andreas Nahr wrote:
>> ----- 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.
>
> stuff on the ldstr table is in unicode. That assumes that the 20 consts
> never get used, however. If they are used in the code at all, they will
> need to be in the ldstr table.
>
>> 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.
>
> They don't.
>
>> >
>> >> 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 ;)
>
> That's correct.
>
> Anyways, as I said to Kornel, Feel free to come back with data about
> what effect the optimization will have. Otherwise, let's just spend time
> on real performance issues with measurable results.
>
> -- Ben
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>