[Webkit-unassigned] [Bug 176586] Speedometer 2.0: Use keyed algorithm to render lists for Inferno suite

[bugzilla-daemon at webkit.org]

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

--- Comment #9 from Ryosuke Niwa <rniwa at webkit.org> ---
Shiyu, with all due respect, you're misunderstanding the intent of Speedometer benchmark. The goal of Speedometer benchmark is to measure real world performance, not the highly optimized content on Web. If there's some web content that's slow, that's exactly what we'd like to test in the benchmark.

(In reply to Shiyu Zhang from comment #8)
> Thanks for your information. I am a bit hesitant to implement the keyed
> algorithm Inferno into Speedometer along with non-keyed. Would it be more
> reasonable to use one keyed algorithm Inferno in Speedometer instead of
> including two variants of both keyed and non-keyed?

No.

> Keys are highly recommended in React, Preact and any other virtual DOM
> library/framework when handling items in lists. This is clearly stated in
> the guide docs of Inferno, React and Preact. React will even give a warning
> that a key should be provided for list items in the console. Given that we
> have limited information on the Inferno users' choice in the wild world,
> would it be more reasonable to assume that most web developers have good
> will to follow the suggestion to use keyed lists?

We do have a very important information: Inferno supports non-keyed algorithm. It means that any real website can end up deploying Inferno with non-keyed algorithm. In fact, Inferno example in TodoMVC currently included in Speedometer 2.0 DID use the non-keyed algorithm!

> As the Inferno author also
> confirmed that a keyed list should be getting used by most Inferno users. If
> that's the case, it makes more sense to keep just keyed algorithm and
> removes the non-keyed implementation, doesn't it?

Absolutely not. The goal of Speedometer isn't to measure the performance of well behaving or even well written Web apps. It is to measure the performance of real Web applications. If there is some pathology that a library/framework user could encounter, then that test case should certainly be included in Speedometer.

> Besides, as we have observed via Chrome Performance tool, the bottleneck of
> Inferno case is the horrible large changes in DOM tree and layout thrashing
> caused by non-keyed algorithm.

Given that this could happen in real life, and it DID happen in real life, it's of utmost interests to us to test non-keyed version of Inferno. In fact, I'd even argue that keyed algorithm is less variable as that's already fast in many browsers.

> Other than blaming the web engine for this,
> maybe it's more reasonable to educate the web developers to avoid codes that
> causes layout thrashing like non-keyed lists. Thus, including a non-keyed
> Inferno case in Speedometer seems to have little practical value in guiding
> browsers to optimize their web engine when the major performance loss lies
> on the misuse of non-keyed lists.

Absolutely not.

> Meanwhile, the time of running the benchmark was also enlarged by duplicated
> Ember and Inferno cases, it would be more than appreciated to have the
> duplicated ones removed, keep the benchmark clean and neat, and reduce the
> total time of the benchmark execution.

First off, the runtime increase caused by Inferno is negligible.

Even if it were, that would be an argument for not including the keyed version of Inferno. If some test case is so slow that it's causing a problem in a benchmark, it's surely going to cause a bad user experience in real life.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170930/3b59157c/attachment-0001.html>