Hi, I like the original version which contained managed arrays better. The new version might use less memory, but it contains lots of unsafe code using pointers, and this will become a problem when we want to do a security audit for moonlight.
Zoltan On Jan 9, 2008 7:45 PM, Andreas Nahr <[EMAIL PROTECTED]> wrote: > I like the patch a lot and am looking forward to see some final speed > results. > > On the other hand when taking into account the importance and size of the > patch several people should look over it ;) > > Greetings > Andreas > > > -----Ursprüngliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Im Auftrag > > von Eyal Alaluf > > Gesendet: Mittwoch, 9. Januar 2008 10:03 > > An: Miguel de Icaza > > Cc: mono-devel-list@lists.ximian.com > > Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace > > > in Mono revisited > > > > Hi, Miguel. > > > > Can I go ahead and commit this important patch? > > > > Thanks, Eyal. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Eyal Alaluf > > Sent: 06 January 2008 16:34 > > To: Andreas Nahr; Prakash Punnoor; mono-devel-list@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:[EMAIL PROTECTED] > > Sent: 04 January 2008 00:26 > > To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor'; > > mono-devel-list@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/metada > ta/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@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list