[Webkit-unassigned] [Bug 90375] Parallel image decoders

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=90375





--- Comment #7 from Kwang Yul Seo <skyul at company100.net>  2012-07-09 16:06:56 PST ---
(In reply to comment #6)
> The results looks weird:
>  * Reference (page cached): 1204 ms (stddev: 11ms)
>  * Threaded (page cached): 58 ms (stddev: 48ms)
> How many core do you have on the test machine that you have a 20x performance boost?

I realized that the test result here is a bit misleading because we measured the page loading time, not the actual image decoding time. So even after page loading is finished, it is still possible that many images are not actually decoded.

I will measure time to the first paint instead as Maciej suggested in webkit-dev mailing list.

> 
>  * Reference: 3759 ms (stddev: 229 ms)
>  * Threaded: 3652 ms (stddev: 117 ms)
> Why is the gain so small in this case?

This test case contains 35 big images so it spends most of time in fetching data from network if the images are not already in the cache. Because WebKit has plenty of spare time to decode, it is hard improve page loading time by just speeding up image decoders.

> 
> I don't know much about Methanol but I have seen ridiculous claim coming from it before so I would prefer if you have some analysis of the results.

Methanol is a kind of page load test. We locally cached Alexa Top 25 sites. Methanol automatically loads each page 10 times and measures page loading time. 

Because most of these sites do not have big images, parallel image decoders are seldom used. We wanted to make sure that there is no performance regression in this case.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.