GNOME Bugzilla – Bug 685693
Slow startup due to user data I/O
Last modified: 2020-11-08 18:13:25 UTC
Here are some very simple measurements of cold startup times with Evolution. Methodology: 0- evolution --force-shutdown 1- Flush the disk caches: "sync && sync && echo 3 > /proc/sys/vm/drop_caches" 2- Start gnome-control-center to have a "minimum" amount of caching for common libraries as would be expected on a normal "cold booted" desktop 3- Start evolution with "time evolution", ctrl+C as soon as the UI shows up My / is a SSD, my /home is a conventional SATA2 hard drive. With the conventional hard drive, "real" cold startup time is 11.5 seconds and warm startup time is ~2.5 seconds Moving ~/.cache/evolution (~13 000 files) to a SSD and putting a symlink instead, cold start becomes 7.5 seconds. When additionally moving ~/.local/share/evolution (15 500 files) to the SSD and symlinking it too, cold start time now becomes 4.7 seconds. I suspect this is unavoidable and the result of the new maildir cache format (lots of little files in a bunch of folders)... Unless you'd tell me that something can be done about it? This brings the following question: should we show a splash screen on startup (with a progressbar indicating progress/stages), or is there a way to make the UI appear sooner and let the rest be populated async (I suppose that's much harder)?
Hi I'd prefer making the UI appear sooner. In my case I have / and /home on an LUKS-encrypted partition on a SSD with >250MB/s read/write and a AES-NI enabled CPU. ~/.cache/evolution/mail contains about 700MB to 1200MB (depending on my mail box size) which leads to cold startup times from 7 to 20 (!) seconds which is really impractical. For comparison (same mail box): Evolution takes 7 seconds Claws-Mail takes <1 second (too fast to measure, you can barely see the delay) Just an idea: We could create an index (some kind of database) for ~/.cache/evolution so that evolution does not need to read ALL data in ~/.cache/evolution on startup. And I prefer to show UI first and populate calendar/mail/adressbook/... later.
Similar downstream bug report from 3.6.3: https://bugzilla.redhat.com/show_bug.cgi?id=910764 User attached there a sysprof, which shows that during evolution's start the most busy part is dconf, which might be due to reading quite many values from it on start. The other slow part can be webkit loading in 3.6.x, though that's just a guess.
I did a little tests, my evolution starts in less than 19 seconds in the "cold start" state. It takes about 4.5 seconds to load webkit libraries - I have a little test application which opens a dialog with the webkitview in itself and then closes. The second start takes like 0.2 second. Then I removed module-settings.so from evolution's module file - it's a module which takes care of many (most) object(s) properties and their connection to the GSettings, thus apparently dconf. The difference with and without this module is around 3 seconds. To be fair, using GSetting's "memory" backend doesn't change the start time ($ time `GSETTINGS_BACKEND=memory evolution`). So it's almost half of the time spent on this. I played a bit with oprofile, namely running it in some empty folder: $ operf -g `which evolution` Then getting the result: $ opreport --demangle=smart --symbols `which evolution` \ --session-dir=oprofile_data samples % image name symbol name 3493 5.7050 ld-2.21.so do_lookup_x 2131 3.4805 ld-2.21.so strcmp 2036 3.3253 libc-2.21.so _int_malloc 1465 2.3927 libglib-2.0.so.0.4400.1 g_slice_alloc 1261 2.0595 libc-2.21.so free 1198 1.9567 libglib-2.0.so.0.4400.1 g_hash_table_lookup 1176 1.9207 libc-2.21.so malloc 1101 1.7982 p11-kit-trust.so /usr/lib64/pkcs11/p11-kit-trust.so 1091 1.7819 libc-2.21.so __strcmp_sse2_unaligned 1049 1.7133 libgtk-3.so.0.1600.6 /usr/lib64/libgtk-3.so.0.1600.6 815 1.3311 libglib-2.0.so.0.4400.1 g_mutex_unlock 813 1.3278 libglib-2.0.so.0.4400.1 g_mutex_lock 812 1.3262 libglib-2.0.so.0.4400.1 smc_notify_free 751 1.2266 libglib-2.0.so.0.4400.1 g_str_hash 733 1.1972 ld-2.21.so _dl_map_object 709 1.1580 libtasn1.so.6.4.2 /usr/lib64/libtasn1.so.6.4.2 666 1.0878 libc-2.21.so realloc There are more, but these are for those with more than 1%. It can produce also callgraphs: $ opreport -cl --demangle=smart --symbols `which evolution` but I'm not going to paste it here. If I read it correctly, then there is not much to be done with the "cold start", due to many of the things being system related, when the kernel caches libraries and other data files. If having a splash screen would help I cannot tell, I do not know it. I neither have a proper graphic for it. The applications with splash I currently recall are GIMP and LibreOffice, both showing progress of the loading. The progress is not an option for the evolution, due to the libraries not being loaded in any trackable way (the modules are extensions, which are created on demand, when the object they extend is constructed).
I guess having a splash screen is controversial, some people don't like it since it is a window with no useful content. I personally don't like that. With WebKit moving into a separate process (WebKit2, webkitgtk4 package on Fedora) shouldn't evolution be starting faster? To make the problem completely go away (on the long term) Evolution might need to do all the indexing asynchronously. In this case the Evolution window may open and display the mail folder structure "instantly" (i.e. <0.5s) and load the other folder contents in background while the UI is ready to be used.
I also do not like the idea of the splash screen. There are two issues, one is initialization of all the "modules" evolution uses, which involves semi-large structures being populated with their property change notifications install, and with the property read from the settings. These things can be done only in the UI thread, which means frozen UI in the way you suggest to do it, which might be even worse than "hidden delay on start". The other issue is library loading. Evolution depends on quite few dynamically loaded libraries, which also takes its time. WebKitGTK+ is one of the biggest libraries evolution uses. There cannot be done anything on this side, as far as I know, the libraries are loaded on demand, also in the UI thread. Whether WebKit2 will help or not I'm not sure (see bug #751588 for the port to it). I've a little WebKit2 test application, and it also starts quite slowly here, after the cache cleanup as suggested in comment #0.
Hi, is this still a problem in a recent Evolution version (currently 3.38)? Asking as some parts of the code base and underlying dependencies changed in the meantime.
It's ok for me with evolution-3.38.1-1.fc33.x86_64, even though I am using Evolution on a 10 years old computer with an SSD model from around 2013. With my 35k files in ~/.local/share/evolution/mail it takes about 3 seconds to start evolution (full disc encryption enabled). Having it faster would be nicer, of course, but I don't think it is slow.
Thanks for the feedback!