[Mono-bugs] [Bug 78016][Nor] Changed - Low performace of new array

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lupus at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78016

--- shadow/78016	2006-04-05 14:25:02.000000000 -0400
+++ shadow/78016.tmp.30984	2006-04-06 09:21:35.000000000 -0400
@@ -69,6 +69,25 @@
 
 
 ------- Additional Comments From marek.safar at seznam.cz  2006-04-05 14:25 -------
 Oh, come on !
 
 The monkeys can do it better ;-)
+
+------- Additional Comments From lupus at ximian.com  2006-04-06 09:21 -------
+FYI: with the new GC this test runs in 1.56 vs 2.39 with the Boehm GC
+on my system. Thread-local allocation is not yet done and locking
+represents 15-20% time in the profile, so expect more improvements as
+well (and more when we'll avoid going to the unmanaged world, since it
+will be possible to alloc from the thread-local pool without the
+expensive transition).
+That said, the rest of the improvements will come from the runtime and
+JIT. Listing them here if someone wants to implement them before I
+found the time myself.
+*) the array element size must be precomputed and stored in MonoClass
+(reusing the class_size field).
+*) the jit will recognize the InitializeArray call with a constant
+RuntimneFieldHandle, get the pointer to the data and insert a call to
+string.memcpy(). Ptoper checks are needed, but in most cases they
+values are constant at jit time.
+When all of this is implemented we'll still be likely 40-50% slower,
+probably, but it's much better than 5+ times:)