Description of problem: ======================= First, this is not related to the GTK spinners bug. I have disabled the status bar on all my Evos to prevent that from happening. This version of evolution is extremely slow to start up. On my Single-CPU P4-3Ghz it takes 29-30 seconds _more_ than the previous (f17) version and during that time the CPU is all maxed out. Closing also usually takes longer and in some cases it took several _minutes_. Opening and closing single messages also takes 4-8 seconds, which is not normal. Search folders work much slower than with the previous f17 release. I tested with my mail database (a litte more than 2gigs) and with a bigger database (about 18Gigs) on a customer's machine which has a 6core 3,6Ghz AMD cpu and an SSD drive. On both machines current evo is much slower than the F17 version. To be sure it is not a cache/.db problem I removed all the various .db, .cmeta, indexes, caches etc. and had evolution parse all anew leading to the same result, and noticing that also the re-parsing takes more time with this release. Version-Release number of selected component (if applicable): ============================================================= evolution-3.6.3-2.fc18.i686 How reproducible: ================= Always with any of my mail databases.
Thanks for a bug report. I believe the slower start is due to the webkitgtk3 being used, as it takes quite some time to load that into memory. The search folders, well, I got an opposite reaction in time of 3.6.x development, I'm not sure whether anything changed in that part, but I'd say there didn't that much, since I received the positive feedback. I think the easiest will be to install debuginfo packages for evolution-data-server, evolution and maybe any other evolution package you've installed and capture a log from Sysprof, what it'll show where evolution spends most of the time. Please note also [1], though it has nothing to do with evolution startup. [1] https://bugzilla.gnome.org/show_bug.cgi?id=683867
Created attachment 700811 [details] sysprof log of Opening and closing evolution I did the opening and closing a first time without the profiling, in order to fill the filesystem caches, and a second time with profiling enabled. This way the time spent waiting on disks should be minimal.
Created attachment 700814 [details] sysprof of "Reply to a message" and "abort the reply" I did the operation on a freshly started evolution and it already shows times longer than on F17. Please tell me i f you need more.
Thanks for the update. I see in the first log that the evolution itself is far behind dconf, which is the most busy process during evolution opening. It can be due to the way evolution starts, it reads many values from GSettings. I thought it was mostly addressed before 3.6.0 release (in time of 3.5.3), but it's obviously insufficient. The second log shows evolution as the second most busy process, right after XOrg, though it seems it's busy on glib/gtk3 stuff, which might be addressed by changes at an upstream bug [2]. I'm moving the slow start to the upstream bugzilla, to an already filled bug [3]. Feel free to CC there, to see any further updates. [2] https://bugzilla.gnome.org/show_bug.cgi?id=689476 [3] https://bugzilla.gnome.org/show_bug.cgi?id=685693
So I suppose we wait for the upstream work to trickle in the fedora repos and then i can test again. Do you know if this work will be back ported to the current F18/evolution-3.6 or if it'll be only in rawhide/evolution-3.7?
> The search folders, well, I got an opposite reaction in time > of 3.6.x development, I'm not sure whether anything changed in > that part, but I'd say there didn't that much, since I received > the positive feedback. I found why searching is so slow for me. I search the full body of messages in many cases and I always had the flag "Index message body data" checked on each of my folders. Now apparently evolution resets the flag "Index message body data" at each reboot, so no indexing happens and searches within message bodies are as slow as molasses. Can we reopen this bug, or shall I open a new one?
There is planned a 3.6.4 release on March 6th, +/-, and after that the evolution update will be available in Fedora 18, at least for the slow composer open due to object leaks. With respect of the index, please file a new bug, and file it in gnome's bugzilla. I do not think it's Fedora specific, thus it belongs there. Thanks in advance.