Bug 154903
| Summary: | Vector<Attribute> in HTMLToken, AtomicHTMLToken, and HTMLStackItem should have inline capacity | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | darin, kling, koivisto |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Ryosuke Niwa
Vector<Attribute> in HTMLToken, AtomicHTMLToken, and HTMLStackItem are copied between each one of these objects.
We should set an inline capacity to make this cheap.
Using Apple's internal page loading tests, it seems like the inline capacity of four will cover 98% of the case:
000: 364295 (57.55%)
001: 151622 (23.95%)
002: 67306 (10.63%)
003: 27133 (4.29%)
004: 10035 (1.59%)
005: 7317 (1.16%)
006: 2226 (0.35%)
007: 1587 (0.25%)
008: 1137 (0.18%)
009: 192 (0.03%)
010: 48 (0.01%)
011: 6 (0.00%)
013: 18 (0.00%)
014: 3 (0.00%)
015: 21 (0.00%)
016: 54 (0.01%)
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ryosuke Niwa
<number of attributes per element> : <count of such elements> (<percentage>)
Darin Adler
Before making this change we should be sure to understand the performance of moving a Vector with inline capacity vs. the performance of moving a Vector with no inline capacity. We will definitely speed things up by avoiding a heap allocation for each Vector when creating it, but we might incur a cost when moving the vector between objects.
If we are copying rather than moving, then I suppose it’s guaranteed to be a win.
Darin Adler
Here's that same data, totaled up:
0: 57.55 42.45
1: 81.50 18.50
2: 92.13 7.87
3: 96.42 3.58
4: 98.01 1.99
5: 99.17 0.83
6: 99.52 0.48
7: 99.77 0.23
8: 99.95 0.05
9: 99.98 0.02
I am not sure that between 4 and 5 is the obvious place to break.
Ryosuke Niwa
(In reply to comment #2)
> Before making this change we should be sure to understand the performance of
> moving a Vector with inline capacity vs. the performance of moving a Vector
> with no inline capacity. We will definitely speed things up by avoiding a
> heap allocation for each Vector when creating it, but we might incur a cost
> when moving the vector between objects.
>
> If we are copying rather than moving, then I suppose it’s guaranteed to be a
> win.
We're always copying these vectors :( I'm all ears if you can think of a way to avoid copying. It's really silly but I haven't quite figured out how to untangle the dependency between lifetimes of these objects yet.