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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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). + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
