| Summary: | Add class matching to the Selector Code Generator | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Benjamin Poulain <benjamin> | ||||
| Component: | New Bugs | Assignee: | Benjamin Poulain <benjamin> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | barraclough, commit-queue, esprehn+autocc, ggaren, kangil.han, koivisto | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Benjamin Poulain
2013-12-23 12:52:38 PST
Created attachment 219926 [details]
Patch
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. ... 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. (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. (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. (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. Committed r161031: <http://trac.webkit.org/changeset/161031> |