Re: [Evolution-hackers] oprofile & vfolders

[Not Zed <notzed ximian com>]

Might be some lock contention, but might not be, e.g. some hidden n^n algorithms or something.  Although that symbol is inaccurate, no g_async queues are used in the mail code at all.

Since it takes so long, you'd be better off running it inside gdb, and then hitting ctrl-c while it's busy and seeing where it is.

On Sun, 2005-04-03 at 03:23 -0400, Lee Revell wrote:
> I've been trying to track down the slowness in the "Unread Mail"
> vfolder.  The easiest way to reproduce it is to start with all your mail
> read, then mark all the messages in a big folder as Unread.  The message
> list for the "real" folder generates quickly.  (the profile starts here)
> Then click the "Unread Mail" vfolder.  And wait, and wait... 60 seconds
> on my machine for ~16000 messages.  (end profiling)
>
> CPU: CPU with timer interrupt, speed 0 MHz (estimated)
> Profiling through timer interrupt
> samples  cum. samples  %        cum. %     image name               app name                 symbol name
> 40912    40912         52.2230  52.2230    libglib-2.0.so.0.600.3   libglib-2.0.so.0.600.3   IA__g_async_queue_unlock
> 3937     44849          5.0255  57.2484    vmlinux                  vmlinux                  default_idle
> 2029     46878          2.5900  59.8384    vmlinux                  vmlinux                  schedule
> 1847     48725          2.3576  62.1960    libedataserver-1.2.so.4.0.0 libedataserver-1.2.so.4.0.0 (no symbols)
> 1635     50360          2.0870  64.2831    libcamel-provider-1.2.so.3.1.1 libcamel-provider-1.2.so.3.1.1 (no symbols)
> 1602     51962          2.0449  66.3280    libcamel-1.2.so.0.0.0    libcamel-1.2.so.0.0.0    (no symbols)
> 1444     53406          1.8432  68.1712    vmlinux                  vmlinux                  __mcount
> 1418     54824          1.8100  69.9812    libc-2.3.2.so            libc-2.3.2.so            __GI___strcasecmp
> 1110     55934          1.4169  71.3981    libc-2.3.2.so            libc-2.3.2.so            __GI_strcoll
> 1077     57011          1.3748  72.7729    libglib-2.0.so.0.600.3   libglib-2.0.so.0.600.3   IA__g_string_truncate
> 998      58009          1.2739  74.0468    libc-2.3.2.so            libc-2.3.2.so            __memalign_internal
> 793      58802          1.0122  75.0590    vmlinux                  vmlinux                  mcount
> 703      59505          0.8974  75.9564    libglib-2.0.so.0.600.3   libglib-2.0.so.0.600.3   IA__g_hook_unref
> 694      60199          0.8859  76.8423    libglib-2.0.so.0.600.3   libglib-2.0.so.0.600.3   g_hash_table_foreach_remove_or_steal
> 681      60880          0.8693  77.7115    libglib-2.0.so.0.600.3   libglib-2.0.so.0.600.3   IA__g_hash_table_find
>
> I don't quite know what to make of all that time in
> IA__g_async_queue_unlock.  Seems like some kind of race condition, or an
> inefficient locking scheme.
>
> I'm building the rest of the libraries with debug symbols now...
>
> Lee
>
>
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers