[Evolution-hackers] oprofile & vfolders

[Lee Revell <rlrevell joe-job com>]

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