-
Notifications
You must be signed in to change notification settings - Fork 471
TabContext.onGC has bad scalability on FF #540
Comments
Thanks for the investigation/insight, I didn't know about
So the way I understand this, I would have to double-check whether the weak browser reference is really valid by looking up => ID? |
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. |
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 Alternatively there is |
If this works well, I will import the changes into uBO as well. |
Looks good. Haven't seen any more hangs on 0.9.3.5rc1 |
Running the RC with this fix since release, no pb. Is is still planned to port that fix to uBO? |
I've obtained the following profile on a FF session with µMatrix and many tabs.
As you can see the
onGC
function spends many seconds inindexFromBrowser
. I think this might be because tabbrowser.browsers does some XUL and proxy object hocuspocus which then leads to a very inefficientindexOf
I think simply keeping a
WeakMap
of => ID and aMap
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.
The text was updated successfully, but these errors were encountered: