Skip to content
This repository has been archived by the owner on Jul 21, 2021. It is now read-only.

TabContext.onGC has bad scalability on FF #540

Closed
the8472 opened this issue Apr 6, 2016 · 6 comments
Closed

TabContext.onGC has bad scalability on FF #540

the8472 opened this issue Apr 6, 2016 · 6 comments

Comments

@the8472
Copy link

the8472 commented Apr 6, 2016

I've obtained the following profile on a FF session with µMatrix and many tabs.

profiler output

As you can see the onGC function spends many seconds in indexFromBrowser. I think this might be because tabbrowser.browsers does some XUL and proxy object hocuspocus which then leads to a very inefficient indexOf

I think simply keeping a WeakMap of => ID and a Map of ID => weakreference() should reduce the need for cleanup.

All that would be left would be scrubbing of IDs that map to nulled weak references.

@gorhill
Copy link
Owner

gorhill commented Apr 6, 2016

Thanks for the investigation/insight, I didn't know about Components.utils.getWeakReference() -- that would solve the issue I was facing not being able to iterate through a WeakMap. However there is this part in the doc:

just because get() succeeds doesn't mean your object is valid. It might simply not have been garbage collected yet

So the way I understand this, I would have to double-check whether the weak browser reference is really valid by looking up => ID?

@the8472
Copy link
Author

the8472 commented Apr 7, 2016

This probably refers to weak references simply not being aware of any internal lifecycle that an object might have. I.e. they don't get nulled magically just because you close/invalidate/shutdown some object that supports such things.

Whether that's actually a problem depends on downstream consumers of the object returned from the weak reference. It's no different from fishing some old dom node that has long been detached or a channel that has been closed out of some javascript variable.

@the8472
Copy link
Author

the8472 commented Apr 7, 2016

Ah, I looked at the code. In addition to the weakmap/ref stuff this check could be replaced with something else that doesn't need the index operation.

Checking whether the <browser> is still attached to the DOM might be the most efficient way.

Alternatively there is browser.ownerDocument.defaultView.top.gBrowser.getTabForBrowser(browser), but I don't know whether that's any more efficient, I think it might also iterate internally. Edit: it uses a weakmap internally, so it should be a fast way to access it.

@gorhill
Copy link
Owner

gorhill commented Apr 23, 2016

If this works well, I will import the changes into uBO as well.

@the8472
Copy link
Author

the8472 commented Apr 26, 2016

Looks good. Haven't seen any more hangs on 0.9.3.5rc1

@sheepdestroyer
Copy link

Running the RC with this fix since release, no pb. Is is still planned to port that fix to uBO?

gorhill added a commit to gorhill/uBlock that referenced this issue Jun 24, 2016
Noxgrim pushed a commit to Noxgrim/uMatrix that referenced this issue Dec 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants