[Webkit-unassigned] [Bug 156252] We've regressed octane codeload by 8% since the revision before arrow functions

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from GSkachkov <gskachkov at gmail.com> ---
(In reply to comment #0)
> It looks like arrow functions have slowed us down by 8-10%.
> I've ran Octane's code-load benchmarks from the revision
> before arrow functions vs ToT. Here is where we stand:
.... 
> If anybody has ideas on how to speed things up further, or how to speed up
> other parts of the parser, I'm all ears.

I think there is a way how we can  avoid at least one step back when parsing arrow function parameters. 
We can create some variable that will answer if current expression can be arrow function, and will check it during parseConditionalExpression. This function cover both header for arrow function x=> and (x)=>. In this function we will check if symbol => follow after variable or (), if not it is definitely not arrow function, if yes it should be arrow function, and in case we can't parse it, it is mean we have syntax error.  
Some like Proof of concept you can find in attach. 
What do you think if it approach viable and can give some improvement is performance?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160621/8ed44aac/attachment.html>