[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 #14 from Addy Osmani <addyo at chromium.org> ---
> 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.

One observation from the field I've noticed developers ship a mix of proper production code (stripped of debug statements) and non-stripped code irrespective of framework. I've seen this occur with React, Angular and Ember at the very least in part because they historically hadn't made it as straight-forward to just ship the right thing when deploying.

"getting rid of them would also introduce a measurement bias" is a fair position to have. I'm personally on the fence about assuming all production code doesn't include such debug statements.


> 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.

Do you have any links to upstream Ember issues or bugfixes around this that we can take a look at? Anything from either Ember core or benchmarks (DBMon?) where this was an issue would be interesting to look at.

-- 
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/8346329f/attachment.html>