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

Sun Jan 13 11:14:46 EST 2008

Hi, Miguel.

I've committed this patch to the trunk. I have rerun the performance
measurements to get uptodate numbers after the changes made during the
review process. Here are the results:

Mono 1.2.6

Patch

Improvement

12345.ToString("G")

10079

7250

1.39

12345L.ToString("G")

13203

7292

1.81

0.12345.ToString("G")

323750

13769

23.5(!)

1.2345E-200.ToString("G")

6376500

0.12345m.ToString("G")

51078

10086

5.1

12345.ToString()

12406/7781

6277

1.98/1.24

12345L.ToString()

15703/11016

5766

2.7/1.9

The numbers are fairly similar to the results I've got before (see
below) the review.

Some notes:

*       double.ToString is 5% slower then the previous results - which
is to be expected after the last changes made to reduce the memory
consumption.

*       int.ToString() is slower by 10% then the previous results - this
is actually strange since it is slower then the current long.ToString()
by 10%. This must be some quirk of he Mono JIT (I don't see a similar
performance loss when running the algorithm on MS .Net 2.0 runtime). I
do recommend that someone take a look into this - it should be a good
test case for tuning the JIT.

For reference the here are the previous results:

Mono 1.2.6

Patch

Improvement

12345.ToString("G")

10079

7328

1.37

12345L.ToString("G")

13203

7297

1.81

0.12345.ToString("G")

323750

13047

24.8(!)

1.2345E-200.ToString("G")

6376500

14328

445(!!!)

0.12345m.ToString("G")

51078

9875

5.2

12345.ToString()

12406/7781

5687

2.2/1.37

12345L.ToString()

15703/11016

5750

2.7/1.9

Thanks, Eyal.

-----Original Message-----
From: Miguel de Icaza [mailto:miguel at novell.com] 
Sent: 10 January 2008 20:39
To: Eyal Alaluf
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080113/5cb90f5c/attachment.html 