<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [JSC] Implement parsing of Async Functions"
href="https://bugs.webkit.org/show_bug.cgi?id=161409#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [JSC] Implement parsing of Async Functions"
href="https://bugs.webkit.org/show_bug.cgi?id=161409">bug 161409</a>
from <span class="vcard"><a class="email" href="mailto:caitp@igalia.com" title="Caitlin Potter (:caitp) <caitp@igalia.com>"> <span class="fn">Caitlin Potter (:caitp)</span></a>
</span></b>
<pre>So, experimenting with this a bit, I'm finding that those "expensive branches" identified by Yusuke Suzuki can be (mostly) mitigated in the benchmarks by moving their contents to never-inlined functions. I guess this makes the on-stack allocation for the more commonly executed code smaller, and means the only extra work the "commonly executed" code has to do is the interned string comparison (testing if a particular string is "async" or not), which should be pretty cheap.
The biggest one of these in the jQuery benchmark is, according to Instruments.app, the one in parseStatement(). Uninlining these rare branches might be a good way to go, but I'd appreciate a second set of eyes measuring that solution using different tools and settings as well.
Some benchmark runs (just with jquery) with 4 VM runs and 10 inner runs:
```
Collected 40 samples per benchmark/VM, with 4 VM invocations per benchmark. Emitted a call to
gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used
the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark
execution times with 95% confidence intervals in milliseconds.
1)
Baseline Patched
jquery 6.76557+-0.13436 ? 6.89083+-0.08124 ? might be 1.0185x slower
<geometric> 6.76557+-0.13436 ? 6.89083+-0.08124 ? might be 1.0185x slower
2)
Baseline Patched
jquery 7.06592+-0.09167 7.03025+-0.07808
<geometric> 7.06592+-0.09167 7.03025+-0.07808 might be 1.0051x faster
```
So, I dunno, that seems like an improvement over the existing regression to me.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>