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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 12 15:16:04 PDT 2012


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





--- Comment #12 from Eric Seidel <eric at webkit.org>  2012-10-12 15:16:47 PST ---
By hist(In reply to comment #11)
> > Happy to oblidge, but could you restate what data you're looking for, I'm not sure I understand yet?
> 
> I want to know what strings we end up doing a hash lookup for - i don't care if they're interned in the JS engine, as that isn't something we can take advantage of (multiple GC heaps == multiple "unique" versions of the same string).
> 
> What I want is a histogram of strings that require a hash lookup to get to the atomicstring.

Which buckets did you want for such a histogram?  Were you looking for a histogram over strings bucketed by length?  Are you looking for a frequency count based on string content?  (Like "foo" : 1M times, "bar": 9 times, "baz" 75 times)?

I added the following to:

PassRefPtr<StringImpl> AtomicString::add(StringImpl* r)
{
    if (!r)
        return r;
    printf("add\n");
    if (r->isAtomic())
        return r;
    printf("slow\n");
    return addSlowCase(r);
}

And then did run-safari Dromeao/dom-query.html > strings.txt

% grep add strings.txt | wc -l
 151839657
% grep slow strings.txt | wc -l
 115803580

So 76% of all AtomicString(StringImpl*) calls, ended up doing a hash lookup during Dromeao/dom-query.html.

I don't think that number is particularly interesting, other than that it's lower than I expect it to be (I expected something like 99% on this benchmark.)

NOTE: That is counting strings which came into AtomicString() already as a StringImpl.  Meaning they were turned into a String, w/o being atomized (this excludes constants from C++, buffers from the parser, etc.)

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


More information about the webkit-unassigned mailing list