<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - JavaScriptCore performance is very bad on Windows"
href="https://bugs.webkit.org/show_bug.cgi?id=146448#c47">Comment # 47</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - JavaScriptCore performance is very bad on Windows"
href="https://bugs.webkit.org/show_bug.cgi?id=146448">bug 146448</a>
from <span class="vcard"><a class="email" href="mailto:ggaren@apple.com" title="Geoffrey Garen <ggaren@apple.com>"> <span class="fn">Geoffrey Garen</span></a>
</span></b>
<pre>I think it's wrong to focus on re-architecting thread id and stack bounds here.
You'll notice that re-architecting thread id and stack bounds did not make JavaScriptCore competitive with Lua. That's a sure sign that it did not fix the root problem.
The profile shows two things:
(1) We're taking the JSLock just to answer the "is null?" question;
(2) Taking the JSLock does a lot of work.
We can fix (1) by not taking the JSLock just to answer trivial type checking questions. (Similarly, we probably should not take the JSLock just to create trivial types like null.)
Then we should profile again to see if JSLock is still expensive relative to other operations. We can probably make JSLock do a lot less work if we need to.</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>