GNOME Bugzilla – Bug 131865
Galeon slow to start up: Favicon cache
Last modified: 2005-01-27 19:51:21 UTC
It seems that Galeon is getting slower and slower since the beginning of the 1.3 versions. I remember that early 1.3.x versions took around 4 seconds to launch (which was already a bit too much ;-)). The latest versions (1.3.11a) take 10 seconds. I have a modern machine (Athlon 2000+, 512 MB RAM, fast HDD) and am running under Gnome 2.4. I took some time to report the bug because I thought it may just be a temporary problem, but now it seems it isn't... Some info: the bookmarks file is 180kB. favicon_cache is 2MB. history.xml is 2.5MB... (do you want more info ?)
Wow, those files are large ! Could you try moving your history.xml, favicon_cache.xml and favicon_cache directory out of the way, and see if that makes a difference. If it does, please try putting the history.xml back, and then finally the favicon_cache dir and xml file. I think its because of the large history file (it could be the large favicon_cache file as well).
Ok, so after experimenting: - without history & favicon_cache: 4 seconds - with history, without favicon_cache: 4-5 seconds - with history & favicon_cache: 10 seconds The favicon_cache itself is 3.5MB big and contains 700 files. An important note: all the figures above are after rebooting, launching Gnome then Evolution. On the contrary, when galeon has already been loaded once, the slowdown on reload is on the order of 1 second. I think it points to some filesystem thrashing (my /home and /usr partitions are a bit far away from each other, so the HD head could spend much time going back and forth). I think I've read that Firebird developers have decided to defer everything that's not critical _after_ the UI start. Thus they can make the program appear as if it's very quick to boot, and then do some additional processing in the background (BTW, the latest Firebird builds have a very nice smooth scrolling under Linux). Is there a reason the favicon files are that big ? I browse a bit for sure, but I don't think I've changed any parameter relating to favicons... Some files in the favicon_cache directory date back to Nov 7th. ------- Here is a vmstat dump while starting Galeon. It clearly is waiting on IO, but transfer rates are mediocre. $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 1 0 270552 22272 101272 0 0 2248 0 425 1199 25 3 72 0 1 0 0 265076 22436 104932 0 0 3820 0 557 684 6 3 91 0 0 1 0 261924 22596 107496 0 0 2683 0 399 754 5 2 93 0 1 0 0 252764 22740 109932 0 0 2569 292 448 970 9 4 87 0 0 1 0 250784 22744 111080 0 0 1152 0 453 578 6 3 91 0 0 1 0 248388 22744 112212 0 0 1132 0 457 590 14 1 85 0 1 0 0 244616 22884 114676 0 0 2545 0 345 402 34 1 65 0 1 0 0 239912 22956 117460 0 0 2655 0 331 518 62 2 36 0 1 0 0 235276 23044 120304 0 0 2905 72 369 1257 24 1 75 0 2 0 0 234456 23056 121060 0 0 700 0 374 707 14 1 85 0 1 0 0 234452 23056 121060 0 0 0 0 324 1173 10 6 84 0
Thanks this is just what I wanted :) (BTW, the smooth scrolling can be turned on by going to about:config and setting "general.smoothScroll" to true)
Any news on this one ? My Galeon startup times are still in the 10-15 second range... (almost as slow as OpenOffice !)
Created attachment 30905 [details] [review] starting point The idea is to get rid of the separate favicon cache and use Mozilla's caching instead. Here's something to get started. Given an URL it simply loads a GdkPixbuf using Mozilla APIs. Now it just needs moving elsewhere and integrating with the rest :)
This should be sorted in CVS, I have totally written the favicon cache http://mail.gnome.org/archives/cvs-commits-list/2005-January/msg07298.html