WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug