[Webkit-unassigned] [Bug 172439] Figure out why Firefox's score goes up by 40% on Speedometer 2 compared to 1

[bugzilla-daemon at webkit.org]

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

--- Comment #13 from Ryosuke Niwa <rniwa at webkit.org> ---
(In reply to Jan de Mooij from comment #12)
> (In reply to Ryosuke Niwa from comment #11)
> > For example, Ember JS's runtime went up from 535ms to 1236ms in Safari
> 
> One thing I noticed while profiling EmberJS in Firefox is that we spend
> quite a lot of time in debug code, stuff like this in
> addObserverForContentKey:
> 
>   _emberMetalDebug.assert('When using @each to observe the array ' + content
> + ', the array must return an object', typeof item === 'object');
> 
> Here they concatenate an array of objects to a string, so we end up with a
> string containing "[object Object],[object Object],[object Object]...".
> 
> We can all optimize this in our engines, but it seems pretty silly to have
> this kind of code in these benchmarks/frameworks. Similar issues have been
> fixed upstream (in Ember) as it came up in other Ember benchmarks too.

On one hand, it seems silly but on the other hand if it's actually in Ember.js, then it 's probably also pushed to the production code. At that point, we might be on hook to optimize that code.

We also see console errors like assertion failures and exceptions getting throwing on production websites all the time. We could argue that those things are silly too but at the same time, getting rid of them would also introduce a measurement bias so we need to be careful in "fixing" these silly things libraries and frameworks do.

-- 
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/20170531/c18e9773/attachment-0001.html>