NEW 154903
Vector<Attribute> in HTMLToken, AtomicHTMLToken, and HTMLStackItem should have inline capacity
https://bugs.webkit.org/show_bug.cgi?id=154903
Summary Vector<Attribute> in HTMLToken, AtomicHTMLToken, and HTMLStackItem should hav...
Ryosuke Niwa
Reported 2016-03-01 19:59:37 PST
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
Ryosuke Niwa
Comment 1 2016-03-01 20:00:43 PST
<number of attributes per element> : <count of such elements> (<percentage>)
Darin Adler
Comment 2 2016-03-02 08:29:45 PST
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
Comment 3 2016-03-02 08:38:45 PST
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
Comment 4 2016-03-02 10:25:51 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.