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

[Kornél Pál]

I think that these removals could result in disk space save rather than in
much better performance. Anyway I think eliminating unnecessary data is good
altough is not critical. Now I understand why it's better to have
optimalizers outside compilers but I think compilation performance may be
better if these optimalizers were included in compilers or integrated with
compilers because there were less binary emitting and reloading.

Note that the things I said earlier in this thread and above are only a
discussion about possible optimizations based on theoritical facts not on
measurements.

BTW what about the 2.0.0.0 patch?

Kornél

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


> On Fri, 2005-07-29 at 11:00 +0200, Kornél Pál wrote:
>> 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.
>
> These optimizations would have to be written N times where N is the
> number of languages we have compilers for. With cecil we write 1
> optimizer. It is like having a jit -- reduces the number of times we
> need to write code.
>
> Now, with that being said. Those of us doing optimization will probably
> focus on optimizations that will result in visible speedups, rather than
> random, unbenchmarked, pie-in-the-sky ideas.
>
> Please don't bother to respond unless you have performance data on how
> this change would benefit users. Showing the difference in du does not
> qualify here. You would need to show:
>
>      * What (if any) runtime data structures are avoided in normal
>        execution
>      * Savings in the number of pages that get paged in for an
>        application with a normal workload.
>
> I don't think we even have the tools (at least on Linux) to measure the
> second item. (I've been begging rml for these ;-).
>
> -- Ben
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>