Closed
Bug 1355201
Opened 8 years ago
Closed 8 years ago
Nuking wrappers is too slow
Categories
(Core :: XPConnect, enhancement)
Core
XPConnect
Tracking
()
RESOLVED
DUPLICATE
of bug 816784
Performance Impact | ? |
People
(Reporter: kmag, Unassigned)
References
Details
Nuking content windows is one of the biggest single chunks of overhead I see when profiling content scripts in tp5o tests, and nuking content script sandboxes just adds to it.
When we destroy a window with multiple frames, we wind up nuking the wrappers for each of them in separate operations. I suspect we could speed things up significantly by adding a timeout, and nuking the wrappers for all windows that are destroyed withing the timeout window in a single operation.
As a bonus, any windows or sandboxes that happen to be collected before the timeout elapses won't have to be nuked at all.
Alternatively, maybe we should just set a flag on the compartments and handle the nuking the first time we trace the wrapper table after we set it. Checking the flag might add a measurable bit of overhead to each GC, as opposed to once per compartment nuke, but it looks like a lot of the overhead is in the UncheckedUnwrap calls, which we already get for free when we're tracing the wrapper tables.
Comment 1•8 years ago
|
||
This sounds like a dupe of bug 816784. I think Ting is looking into it.
Reporter | ||
Comment 2•8 years ago
|
||
Ah, indeed. And good timing, too.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Updated•3 years ago
|
Performance Impact: --- → ?
Whiteboard: [qf]
You need to log in
before you can comment on or make changes to this bug.
Description
•