Bug 126176 - Add class matching to the Selector Code Generator
Summary: Add class matching to the Selector Code Generator
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Benjamin Poulain
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-23 12:52 PST by Benjamin Poulain
Modified: 2013-12-23 15:43 PST (History)
6 users (show)

See Also:

Attachments
Patch (12.21 KB, patch)
2013-12-23 12:54 PST, Benjamin Poulain 		koivisto: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Poulain 2013-12-23 12:52:38 PST 
Add class matching to the Selector Code Generator
Comment 1 Benjamin Poulain 2013-12-23 12:54:46 PST 
Created attachment 219926 [details]
Patch
Comment 2 Antti Koivisto 2013-12-23 13:59:01 PST 
Comment on attachment 219926 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=219926&action=review

It might be good if someone who knows the marcoassembler would also take a look.

> Source/WebCore/cssjit/SelectorCompiler.cpp:209
> +    HashSet<const AtomicStringImpl*> fragmentClassNames;

Repeating class names are probably very rare. It may be better to just use a vector and not care about removing duplicates.
Comment 3 Antti Koivisto 2013-12-23 14:08:12 PST 
... with inline capacity. Even if duplicates are removed doing it in vector is likely still be much faster as there are rarely many entries. HashSets always malloc so are expensive.
Comment 4 Benjamin Poulain 2013-12-23 14:41:16 PST 
(In reply to comment #3)
> ... with inline capacity. Even if duplicates are removed doing it in vector is likely still be much faster as there are rarely many entries. HashSets always malloc so are expensive.

This is compile time though so this code is very not hot.
Comment 5 Antti Koivisto 2013-12-23 14:54:59 PST 
(In reply to comment #4)
> (In reply to comment #3)
> > ... with inline capacity. Even if duplicates are removed doing it in vector is likely still be much faster as there are rarely many entries. HashSets always malloc so are expensive.
> 
> This is compile time though so this code is very not hot.

Compile time can matter as we may have large numbers of selectors. Rule analysis code during RuleData construction shows up in profiles (0.7% of PLT3) and is analogous to selector compiling.
Comment 6 Benjamin Poulain 2013-12-23 15:15:49 PST 
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > ... with inline capacity. Even if duplicates are removed doing it in vector is likely still be much faster as there are rarely many entries. HashSets always malloc so are expensive.
> > 
> > This is compile time though so this code is very not hot.
> 
> Compile time can matter as we may have large numbers of selectors. Rule analysis code during RuleData construction shows up in profiles (0.7% of PLT3) and is analogous to selector compiling.

Ok. I'll switch to a vector then.
Comment 7 Benjamin Poulain 2013-12-23 15:43:47 PST 
Committed r161031: <http://trac.webkit.org/changeset/161031>