[Webkit-unassigned] [Bug 99118] JSC Should atomize constant strings before handing them to WebCore

[bugzilla-daemon at webkit.org]

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





--- Comment #9 from Eric Seidel <eric at webkit.org>  2012-10-12 13:33:19 PST ---
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #5)
> What I was wanting to know is how many unique strings end up missing the cache hit (i mean non-Atomic strings coming from JS)?

Do you mean specific to this benchmark?  Or some larger set of pages?

My understanding is that any string created in JS, by JSC, will be Interned, but never be an AtomicString, and thus need to go through a hash lookup before it can be used in WebCore as an AtomicString?

Every DOM API which takes an AtomicString as a parameter, will require a Hash lookup when taking a string from JSC, if I'm understanding correctly.  If JSC got the string from the DOM/WebCore originally and handed us back the same StringImpl, then we'd avoid this hit of course.

> Some stats on what those strings are just accumulated via printf logging into a histogram.
> 
> Depending on the spread I have an idea for a way to greatly improve the lookup speed even on a miss, when the string is already present in the Atomics table.

Happy to oblidge, but could you restate what data you're looking for, I'm not sure I understand yet?

It sounds like you'd be interested in having some information on how often a StringImpl which came from JSC is used for a hash lookup in AtomicString?  Or maybe how often an Interned string from JSC is?  I assume over something like the PLT or some representative set of pages?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.