Bugzilla – Bug 7104
GD image resizing is painfully slow
Last modified: 2009-09-08 09:21:09 UTC
I benchmarked the GD operations we perform for every image resize and my 3Ghz server can only do 15/second. The big problem is copyResampled(). Need to find a faster way of doing our resize.
Created attachment 2848 [details] GD benchmark script My benchmark script. The Imager section was to see if the Imager filtering we're doing on Windows was causing any performance impact, the answer to that question is no.
see also bug 7087
Something strange going on here Andy, your script gives the following for me: Benchmark: running gd, imager for at least 5 CPU seconds... gd: 5 wallclock secs ( 5.03 usr + 0.08 sys = 5.11 CPU) @ 25.83/s (n=132) imager: 5 wallclock secs ( 5.21 usr + 0.13 sys = 5.34 CPU) @ 37.08/s (n=198) Different image: gd: 5 wallclock secs ( 5.26 usr + 0.04 sys = 5.30 CPU) @ 13.58/s (n=72) imager: 5 wallclock secs ( 4.98 usr + 0.15 sys = 5.13 CPU) @ 10.53/s (n=54) So imager can be slow?
Created attachment 2853 [details] Image used for my benchmark Here's the file I used for my benchmark, a 512x512 jpeg. I figure it's a pretty normal sized file similar to what people will have.
Update to my benchmark, the Imager filter is also really slow, but we can't really do anything about that right now.
Is 15/sec really that slow? This is all cached, so it's a one-time hit...
not for those who rescan daily (there ARE those that do), nor for those of us who have to hear the complaints as people focus on timing the scans :)
Created attachment 2854 [details] GD benchmark script Fixed version of benchmark script
Note to self: pre-caching should only cache one image per album, not one image per track.
A regular rescan should not regenerate all the image data. A daily wipe-and-rescan shouldn't be necessary for anybody but the most insane.
using attached image: Benchmark: running gd, imager for at least 5 CPU seconds... gd: 5 wallclock secs ( 4.98 usr + 0.02 sys = 5.00 CPU) @ 10.00/s (n=50) imager: 5 wallclock secs ( 5.44 usr + 0.10 sys = 5.54 CPU) @ 19.13/s (n=106) model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ cpu MHz : 1908.768 cache size : 512 KB
The first thing I'm going to work on in trunk is requesting cover images without an extension and serving the best type of file. This means square images can be jpeg which processes a bit faster than png, and results in much smaller files.
I think we should offer a preference to avoid doing all this work at artwork scan time. I feel this could be something like the original cache implementation which caused lots of feedback once 6.5 was launched. If its possible for it to take an hour to do an artwork scan we need to do something about it... I'd also note that we have effectively halved performance for windows because a few users had crashes - is this the right trade off?
Checked in my serve-square-JPEG-as-JPEG fix as change 17980. Also serves JPEG to Jive for those images. The Jive performance seems OK to me but could use some benchmarking.
Marking fixed, we can't really speed up GD but we have improved Jive and web speed by using JPEG.
(In reply to comment #15) > Marking fixed, we can't really speed up GD but we have improved Jive and web > speed by using JPEG. > Closing bug
Reduce number of active targets for SC