<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#c50">Comment # 50</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:peavo@outlook.com" title="peavo@outlook.com">peavo@outlook.com</a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=146448#c47">comment #47</a>)
<span class="quote">> 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.</span >
Thanks, these are good points :) I will check the performance without locking in the trivial cases. Maybe we can include the stack bounds optimization on Windows as well?</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>