[Webkit-unassigned] [Bug 156147] [JSC] implement async functions proposal

[bugzilla-daemon at webkit.org]

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

--- Comment #111 from Saam Barati <sbarati at apple.com> ---
(In reply to comment #110)
> (In reply to comment #109)
> > Comment on attachment 280020 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=280020&action=review
> > 
> > >> Source/JavaScriptCore/parser/Parser.cpp:624
> > >> +        if (UNLIKELY(m_runtimeFlags.isAsyncAwaitEnabled() && matchContextualKeyword(m_vm->propertyNames->async))) {
> > > 
> > > There is a chance that this may be faster if the LHS and RHS were swapped because it might aid the register allocator. 
> > > Same with the similar compare elsewhere.
> > > Is this what's slowing down the parser?
> > > Have you tried making ASYNC a key word? That may be faster than checking the IDENT's StringImpl
> > 
> > When executing `matchContextualKeyword(m_vm->propertyNames->async)`, it
> > becomes `Identifier == Identifier` check and it should be pointer comparison
> > because Identifier is already interned.
> 
> I was just thinking that we may get almost identical codegen (or we would
> get slightly worse codegen but the machine's branch/indirect jump prediction
> would make up for it) for the 'switch' statement if we made ASYNC a keyword,
> and we wouldn't have this branch at each IDENT. But maybe this would cause
> slow downs elsewhere. I'm not sure. It's hard to predict without
> implementing it and measuring perf.
Actually, a good starting point is to see if these branches are actually what the remaining slow down is. Because octane/code-load doesn't use async/await, we can probably get away with removing the branch and seeing if the entire regression goes away. If it doesn't, we know there is slow down elsewhere.

-- 
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/20160528/7d41ff2c/attachment.html>