[Mono-bugs] [Bug 75444][Nor] Changed - [GMCS] bad generic method instantations performance

[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 malekith at pld-linux.org.

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

--- shadow/75444	2005-07-02 19:50:55.000000000 -0400
+++ shadow/75444.tmp.15882	2005-07-03 12:02:28.000000000 -0400
@@ -183,6 +183,66 @@
 7076      0.3929  mono_burg_label_priv
 7037      0.3908  mono_marshal_get_runtime_invoke
 7033      0.3905  GC_find_header
 5855      0.3251  mono_runtime_class_init
 5807      0.3225  EnterCriticalSection
 
+
+------- Additional Comments From malekith at pld-linux.org  2005-07-03 12:02 -------
+The output above was after the change, for nemerle compiler compiling
+the standard library. I have however found the results to be somewhat
+bogus, for instance it reported mono to sit in g_error in
+mono_type_stack_size(), which clearly wasn't the case.
+
+Lupus suggested I use --profile=default:stat and it seems to work. One
+interesting thing I noticed is finalization. We do not have any
+Finalize methods, and I don't think we use much of objects with
+Finalize from the BCL. Indeed in the nongeneric compiler version first
+entry about finalization is at 0.12%. However in the generic version:
+
+prof counts: total/unmanaged: 18792/17154
+   5158 27.45 % /home/users/malekith/mono-svn/bin/mono(GC_mark_from
+   1483  7.89 % /home/users/malekith/mono-svn/bin/mono(GC_finalize
+    587  3.12 % /usr/lib64/libglib-2.0.so.0(g_hash_table_insert
+    486  2.59 % /home/users/malekith/mono-svn/bin/mono(GC_find_header
+    367  1.95 % /usr/lib64/libglib-2.0.so.0
+    351  1.87 %
+/home/users/malekith/mono-svn/bin/mono(GC_register_finalizer_inner
+    336  1.79 % /usr/lib64/libglib-2.0.so.0(g_hash_table_lookup
+    331  1.76 % /lib64/tls/libc.so.6
+    268  1.43 % /lib64/tls/libpthread.so.0
+    266  1.42 % /home/users/malekith/mono-svn/bin/mono(GC_reclaim_clear
+    239  1.27 % /lib64/tls/libc.so.6(calloc
+    232  1.23 %
+/home/users/malekith/mono-svn/bin/mono(mono_arch_local_regalloc
+    221  1.18 %
+/home/users/malekith/mono-svn/bin/mono(mono_generic_inst_equal
+    215  1.14 % /lib64/tls/libc.so.6(memset
+    214  1.14 % /lib64/tls/libpthread.so.0(__pthread_mutex_lock
+    211  1.12 %
+/home/users/malekith/mono-svn/bin/mono(do_mono_metadata_type_equal
+    200  1.06 % /home/users/malekith/mono-svn/bin/mono(GC_base
+    176  0.94 %
+/home/users/malekith/mono-svn/bin/mono(mono_burg_label_priv
+    156  0.83 % /home/users/malekith/mono-svn/bin/mono(GC_is_marked
+    152  0.81 %
+/home/users/malekith/mono-svn/bin/mono(_mono_metadata_generic_class_equal
+    136  0.72 % /home/users/malekith/mono-svn/bin/mono(mono_method_to_ir
+    135  0.72 % /home/users/malekith/mono-svn/bin/mono(GC_local_gcj_malloc
+    131  0.70 %
+/home/users/malekith/mono-svn/bin/mono(mono_metadata_generic_param_equal
+    120  0.64 %
+/home/users/malekith/mono-svn/bin/mono(mono_object_new_alloc_specific
+    109  0.58 %
+/home/users/malekith/mono-svn/bin/mono(mono_metadata_decode_row
+    105  0.56 %
+/home/users/malekith/mono-svn/bin/mono(mono_arch_output_basic_block
+     93  0.49 % /lib64/tls/libc.so.6(__libc_free
+
+(this is all after my change).
+
+GC_mark_from was 24% in the non generic version, but it is 5x faster,
+therefore it seems to take more time. Maybe because of finalizers.
+The generic version allocates 170M (non generic 140M, this is strange,
+the generic version doesn't box anything, so it should allocate less,
+maybe it's some runtime issue).
+