Bug 132548

Summary: Optimize JSRopeString for resolving directly to AtomicString.
Product: WebKit Reporter: Andreas Kling <kling>
Component: JavaScriptCoreAssignee: Andreas Kling <kling>
Status: RESOLVED FIXED    
Severity: Normal CC: barraclough, benjamin, cdumez, cgarcia, cmarcelo, commit-queue, darin, esprehn+autocc, fpizlo, ggaren, kangil.han, kling, kondapallykalyan, rniwa
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch fpizlo: review+

Description Andreas Kling 2014-05-04 13:51:48 PDT
We could make JSRopeString smarter when we know the output is going to be used as an AtomicString.
Comment 1 Andreas Kling 2014-05-04 14:19:01 PDT
Created attachment 230792 [details]
Patch
Comment 2 Andreas Kling 2014-05-04 16:05:19 PDT
Created attachment 230793 [details]
Patch
Comment 3 Benjamin Poulain 2014-05-04 19:31:02 PDT
Comment on attachment 230793 [details]
Patch

I would have done this differently. First use the rope in place to find the AtomicString. If none exist, then create the StringImpl and resolve.

Any reason you went for this two steps resolution?
Comment 4 Andreas Kling 2014-05-04 19:46:22 PDT
(In reply to comment #3)
> (From update of attachment 230793 [details])
> I would have done this differently. First use the rope in place to find the AtomicString. If none exist, then create the StringImpl and resolve.
> 
> Any reason you went for this two steps resolution?

For simplicity. Here we walk the fiber tree once instead of up to 3 times. In your version, we'd have to hash recursively, then check equality recursively and then (worst case) copy into a new string recursively.
Comment 5 Andreas Kling 2014-05-04 21:43:55 PDT
Forgot to mention in ChangeLog, this is a ~20% progression on Dromaeo/dom-query.html
Comment 6 Filip Pizlo 2014-05-04 21:50:20 PDT
Comment on attachment 230793 [details]
Patch

lgtm
Comment 7 Andreas Kling 2014-05-04 23:45:14 PDT
Committed r168256: <http://trac.webkit.org/changeset/168256>