GNOME Bugzilla – Bug 734202
frogr super slow to load photos
Last modified: 2014-10-08 10:52:09 UTC
frogr is super slow to load photos, about 1 second per 5Mb photos... This makes uploading large batches of photos a real pain. Do we really need frogr to read every and each photo before starting a large upload? It seems that even a big pig like firefox is 100 times better at that game...
I've been doing some tests and indeed, frogr is damm slown when loading pictures into the icon view, way more than what it's reasonable. For a batch of 200 pictures of ~5MB each (972M in total, according to 'du'), it took me almost 2 minutes to load them all in the interface: $ time src/frogr /home/mario/TestPictures/*JPG real 1m54.261s user 1m50.510s sys 0m3.504s ...which means almost 0.6 seconds to load each 5MB!! However, I'm happy to say that I found one of the main problems after profiling CPU usage for a while: the _import_tags_from_xmp_keywords() function, which was doing some quite sub-optimal usage of memory and pointers, resulting in a a lot of memory being unnecessarily copied over for each picture loaded, slowing down the process quite a lot. Anyway, I optimized a bit that function (see commit in [1]), and now this is what I get when I try to load the same batch of 200 pictures, of 5MB each: $ time src/frogr /home/mario/TestPictures/*JPG real 0m40.118s user 0m36.880s sys 0m3.373s ...which means "only" 0.2 seconds as much to load each picture, a 300% speed up compared to the previous state. Not bad :) Actually, is almost the same time that would take to load those pictures if you have the "Import tags from pictures metadata" checkbox disabled (in preferences > misc), so you can get a similar speed up already now if importang tags is not important or relevant for you :) Anyway, I feel like there is still room for improvement here, but I'd love to hear from you (Luc) what do you think about this improvement, whether it's enough to resolve the bug or not. What do you think? [1] https://git.gnome.org/browse/frogr/commit/?id=7208fdfb106ede7c7982230bf0d1784e454e6c1d
I'm resolving this bug too, since now loading is much faster than before, and other approaches (e.g. lazy loading thumbnails while loading) is something I'm pretty sure I won't be able to implement anytime soon, so I'd rather close this bug now and maybe reopen it in the future (or file a new one) if we still feel the need for it.
much faster indeed. thanks!