[Mono-dev] [PATCH] ToString() performace in Mono revisited

[Miguel de Icaza]

Hello Eyal,

> Can I go ahead and commit this important patch?

Yes, this is fine with me.

I'll discuss with the team if we want to by default use the TARGET_JVM
option by default ourselves or not.   But for now, lets get the patch
in.

> Thanks, Eyal.
> 
> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Eyal
> Alaluf
> Sent: 06 January 2008 16:34
> To: Andreas Nahr; Prakash Punnoor; mono-devel-list at lists.ximian.com
> Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky
> Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace
> inMono revisited
> 
> Hi, all.
> 
> I have attached a patch following Andreas suggestions below. Please
> review, especially the metadata part.
> 
> I saw once that Mono checks compatibility of Mscorlib with the runtime,
> is this happenening automatically whenever an internal call is added?
> 
> BTW, since now the numberFormatter tables become arrays of magic numbers
> in mono/metadata, is there a place where I should put the program that
> generates these numbers?
> 
> Thanks, Eyal.
> 
> -----Original Message-----
> From: Andreas Nahr [mailto:ClassDevelopment at A-SoftTech.com] 
> Sent: 04 January 2008 00:26
> To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor';
> mono-devel-list at lists.ximian.com
> Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky'
> Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in
> Mono revisited
> 
> > It does make sense to make the 'DblExpTab' common to all appdomains.
> > How do you implement such a scheme in Mono? Is it possible to 
> > achieve this without going out to unsafe code and internal methods?
> 
> Afaik to gain all the advantages you need one internal method to return
> the
> pointers and unsafe code for accepting the pointer.
> The scheme is pretty straightforward (compare Char or CultureInfo):
> Runtime:
> * Pregenerate the table data
> * convert to a C constant array
> * embed that into the runtime (e.g.
> http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metadata/culture
> -inf
> o-tables.h?rev=88796&view=auto)
> * Create one runtime method to return a pointer to the array
> Classlib:
> * Define internalcall to the runtime method
> * Store the retrieved pointer in a static variable
> * Use the pointer as you would use the array (syntax is compatible, so
> no
> need to change the code)
> * Get Array-Bounds-Check-Removal for free :)
> 
> > If the above is complicated, do you think that it makes sense 
> > to consider the above as a separate task since the array size 
> > is now 24K and a scenario with 1000 domains is a rare scenario?
> 
> Well I personally am much more concerned about the additional startup
> cost
> of the current suggestion (Managed already has a high startup cost and
> this
> is measurably increasing it) than the additional memory cost. But not
> everybody will think that way...
> So imho it would be worth implementing in the runtime.
>  
> Greetings Andreas
> 
> P.S. WAY back then I tried to do the same without runtime support by
> acquiring a pointer to an embedded resource file. I don't know if this
> works
> now, but back then it didn't (as far as I can remember).
> A starting point MIGHT be Assembly.GetManifestResourceInternal
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list