[Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
eyala at mainsoft.com
Thu Jan 10 04:32:16 EST 2008
The use of unsafe pointers here is not different then the use of unsafe pointers in System.Char.
I did go ahead and moved all the common arrays to be shared - would it matter if only the two arrays related to double computing will be unsafe? (The 'MantissaBitsTable' and 'TensExponentTable' table).
These are the two arrays that take the most memory.
In any case the version that uses managed arrays will be committed as well and will be marked by '#ifdef TARGET_JVM' since we use this version anyhow for Grasshopper. I don't know if it makes sense for moonlight to have a customized version of Mono where these arrays (and other parts such as System.Char) are managed, but if it does make sense it will be a no brainer.
From: Zoltan Varga [mailto:vargaz at gmail.com]
Sent: 10 January 2008 00:09
To: Andreas Nahr
Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
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
On Jan 9, 2008 7:45 PM, Andreas Nahr <ClassDevelopment at a-softtech.com> wrote:
> I like the patch a lot and am looking forward to see some final speed
> On the other hand when taking into account the importance and size of the
> patch several people should look over it ;)
> > -----Ursprüngliche Nachricht-----
> > Von: mono-devel-list-bounces at lists.ximian.com
> > [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag
> > von Eyal Alaluf
> > Gesendet: Mittwoch, 9. Januar 2008 10:03
> > An: Miguel de Icaza
> > Cc: mono-devel-list at 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: 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/metada
> > -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
More information about the Mono-devel-list