Closed
Bug 1029157
Opened 10 years ago
Closed 10 years ago
Consider removing sCachedComputedDOMStyle
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla33
People
(Reporter: mccr8, Assigned: mccr8)
References
Details
Attachments
(2 files)
5.30 KB,
patch
|
Details | Diff | Splinter Review | |
5.31 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
sCachedComputedDOMStyle is being used to store a single dtor'ed block of memory for a nsComputedDOMStyle, and is pretty scary. In the glorious world of jemalloc, I can't imagine it helps performance. We should try to confirm that, and remove it, assuming it does not regress performance.
Assignee | ||
Comment 1•10 years ago
|
||
I'm not sure exactly what perf testing should be done.
Comment 2•10 years ago
|
||
Not sure I trust jemalloc to be super fast, but the cache was added _long_ ago in Bug 155525, so many things have changed since. Like, SnowWhite kills CDS objects asynchronously. So we may have a cached object right after SnowWhite has run, but once it has been use, the cache won't be there until Snowwhite kills another CDS.
Comment 3•10 years ago
|
||
FWIW, I've removed several custom allocators dating back to pre-jemalloc days, and none of the removals affected performance. I'd be optimistic: remove it, land, and see if you get any regression emails :)
Assignee | ||
Comment 4•10 years ago
|
||
Do you have any thoughts on what sort of test I should run, Boris? As Olli points out, the cache hit rate is probably not very high nowadays anyways.
Flags: needinfo?(bzbarsky)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → continuation
Comment 5•10 years ago
|
||
Oh, this is caching the memory, not an object? Just kill it, and sorry you ended up having to think about this. :( I can't think of cases where it would be useful: in a tight loop we'd not end up with a live thing until GC anyway.
Flags: needinfo?(bzbarsky)
Assignee | ||
Comment 6•10 years ago
|
||
Yeah, it calls the dtor on the object, then sticks it in the global. When you create a new one, it calls the ctor on the block. So it is just saving the malloc/free call, not any initialization.
Assignee | ||
Comment 7•10 years ago
|
||
try run: https://tbpl.mozilla.org/?tree=Try&rev=ff1ece740d55
Attachment #8446025 -
Flags: review?(bzbarsky)
Comment 8•10 years ago
|
||
Comment on attachment 8446025 [details] [diff] [review] Eliminate sCachedComputedDOMStyle. r=me
Attachment #8446025 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 9•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/68dddeca55d2
Comment 10•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/68dddeca55d2
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in
before you can comment on or make changes to this bug.
Description
•