RESOLVED FIXED 71555
[Qt] Compare WebCore and Qt ImageDecoders 
https://bugs.webkit.org/show_bug.cgi?id=71555
Summary [Qt] Compare WebCore and Qt ImageDecoders
Zoltan Horvath
Reported 2011-11-04 05:33:28 PDT
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!
Attachments
alexa top150 (2.76 KB, text/plain)
2011-11-04 07:41 PDT, Zoltan Horvath 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Zoltan Horvath
Comment 1 2011-11-04 05:34:55 PDT
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.
Zoltan Horvath
Comment 2 2011-11-04 07:41:11 PDT
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.
Zoltan Horvath
Comment 3 2011-11-07 01:42:39 PST
(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.
Zoltan Horvath
Comment 4 2011-11-08 04:33:08 PST
(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. :)
Zoltan Horvath
Comment 5 2011-11-09 06:35:25 PST
(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?
zalan
Comment 6 2011-11-11 10:12:10 PST
Kimmo, do you recall what was the actual reason of switching?
Zoltan Horvath
Comment 7 2011-11-18 03:15:56 PST
(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.
Simon Hausmann
Comment 8 2012-02-10 02:00:41 PST
Related bug in this context for a switch: bug #32410
Zoltan Horvath
Comment 9 2012-03-06 02:00:39 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.