The goal of this bug is to measure the performance and memory consumption differences between WebCore imagedecoders and QImageDecoder, furthermore - based on the results and the discussions - we should decide either to keep the current QImageDecoder implementation or change to WebCore's imagedecoders as we changed for WebCore's one for the N9 browser. Setup: Slackware 13.1 - 32 bit, Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz, this is a dedicated pc for benchmarking purposes # Memory consumption (Maximum Resident Set Size (RSS), based on kernels smaps information): Methanol suite with 18 custom sites for benchmark imagedecoding. http://zoltan.sed.hu/WebKit/methanol_imgdecoder/fire.html?iter=1 WebCoreImageDecoders: avg 295 624 kbytes +/- 1.6% (min: 290 804 kbytes, max: 303 334 kbytes) QtImageDecoders: avg 293 556 kbytes +/- 2.1% (min: 286 052 kbytes, max: 303 804 kbytes) Methanol suite with the first individual 23 sites from alexa top100. (mirrored) http://zoltan.sed.hu/WebKit/methanolx/fire.html?iter=1 WebCoreImageDecoders: avg 70 856 kbytes +/- 2.5% (min: 68 772 kbytes, max: 73 736 kbytes) QtImageDecoders: avg 70 639 kbytes +/- 1.1% (min: 70 056 kbytes, max: 72 016 kbytes) As we see there are no big differences in the numbers, the memory consumption is almost the same with both type of implementation. # Performance (Methanol provided the results) http://zoltan.sed.hu/WebKit/methanol_imgdecoder/fire.html?iter=1 QtImageDecoders: avg 15 632 ms +/- 5.1% (min: 14 344ms, max: 16 406ms) WebCoreImageDecoders: avg 20 895 ms +/- 5.6% (min: 19 116ms, max: 22314ms) WebCoreImageDecoder is 33.6% slower. Methanol suite with the first individual 23 sites from alexa top100. (mirrored) http://zoltan.sed.hu/WebKit/methanolx/fire.html?iter=1 QtImageDecoders: avg 7 492ms +/- 6.5% (min: 7 124ms, max: 8 216ms) WebCoreImageDecoders: avg 7 798ms +/- 9.06% (min: 7 332ms, max: 9 153ms) WebCoreImageDecoder is 4.08% slower. Based on this results I think we will keep QImageDecoders, but I'm interested in your thoughts!
I did the measurements with the latest Qt 4.8. If anyone would like to reproduce the results I'd gladly upload my WebCoreImgDecoders patch.
Created attachment 113655 [details] alexa top150 I run the robotized version of QtLauncher for the attached sites.txt, what contains the first 150 urls from today's Alexa Top 1,000,000. MaxRSS WebCoreImageDecoders: 196 576 kbytes QtImageDecoders: 189 000 kbytes I will run the benchmark again to verify the results and I will do measurements for performance on Monday.
(In reply to comment #2) > I will run the benchmark again to verify the results and I will do measurements for performance on Monday. On Tuesday.
(In reply to comment #3) > (In reply to comment #2) I finished memory consumption measurements for the first 150 sites from alexa. WebCoreImageDecoders: avg 206 288 kbytes +/- 5.2% (min: 197 644 kbytes, max: 221 216 kbytes) QtImageDecoders: avg 202 241 kbytes +/- 2.4% (min: 197 748 kbytes, max: 208 584 kbytes) I need to use webpagereplay for performance measurements to leave network connection out of account, so it will take some time. :)
(In reply to comment #4) > I need to use webpagereplay for performance measurements to leave network connection out of account, so it will take some time. :) Well, I finished performance measurements for the first top150 alexa sites. WebCoreImageDecoders: avg 187 051ms +/- 0.3% (min: 185 725ms, max: 189 019ms) QtImageDecoders: avg 187 309ms +/- 0.7% (min: 186 243 ms, max: 188 210ms) Hmm, in this test case the results are similar... what is not surprising, since both implementation use the same system libraries. Any thoughts based on results?
Kimmo, do you recall what was the actual reason of switching?
(In reply to comment #6) > Kimmo, do you recall what was the actual reason of switching? Kimmo, ping! :) I'm curious to hear your answer! Other topic: I made a statistics on loaded image dimensions and I classify them into some groups: x,y,z := pixels (x) (y) (x*y) count(x*y) 2 2 4 553 4 4 16 22 (4 < z <= 16) 8 8 64 74 (16 < z <= 64) 16 16 256 293 ... 32 32 1024 249 64 64 4096 596 128 128 16384 1032 256 256 65536 1080 512 512 262144 297 1024 1024 1048576 89 2048 2048 4194304 7 3072 3072 9437184 0 4096 4096 16777216 0 In the case of x*y < 4px there are 125 0*0px and 394 1*1px images.
Related bug in this context for a switch: bug #32410
(In reply to comment #8) > Related bug in this context for a switch: bug #32410 Related bugs: - bug #80398 - bug #80400 I close this bug, further measurement isn't needed.