Bug 92486
| Summary: | [JSC] JSC should use AtomicStrings to make Element::getAttributeNS() faster | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kentaro Hara <haraken> |
| Component: | WebCore JavaScript | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | abarth, barraclough, eric, ggaren, rniwa, sam |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 99118 | ||
| Bug Blocks: | |||
Kentaro Hara
Assume Node::foo(AtomicString& str). Assume JavaScript calls node.foo("bar").
[V8] V8 can cache both Strings and AtomicStrings. "bar" is cached as an AtomicString. When node.foo("bar") is called, the cached AtomicString is passed to Node::foo(). Very efficient.
[JSC] JSC can cache Strings but cannot cache AtomicStrings. "bar" is cached as a String. When node.foo("bar") is called, the cached String has to be converted to AtomicString and then passed to Node::foo().
For more details, please refer to Comment #0 of bug 90276.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Geoffrey Garen
"Cache" is the wrong term for what happens when JSC passes a string to WebCore. JSC already has a StringImpl*, and it passes that to WebCore.
The issue here is that "foo" is in the Identifier table but not the AtomicString table. One way to fix this is to merge the tables.
Eric Seidel (no email)
I believe bug 99118 and this are the same bug?