Kris Maglione [:kmag] Reporter
	Description • 7 years ago

Looking at the memory dominator tree in a fresh Firefox instance, the blocklist is one of the top items, at over 600K. We don't need to access it very often. At the points when we do, we should be able to load it from JSON and then discard it, or query an indexedDB database and close it, rather than keeping the whole thing in memory.

	Robert Helmer [:rhelmer]
	Comment 1 • 7 years ago

Florian mentioned that he had someone that was interested in being mentored to fix this bug. We may want to adjust the summary a bit, from talking to Kris we agreed that the way to go here was to only compare the list of built-in addon IDs to the blocklist when either the blocklist or the addons db changed, which could all be done async after startup.

Per comment 0 it'd be nice if blocklist was in indexeddb so we didn't need to load the whole thing in memory, but even if we end up loading it all we can at least release it when we're done so I think that work could be split up.

	Kris Maglione [:kmag] Reporter
	Comment 2 • 7 years ago

(In reply to Robert Helmer [:rhelmer] from comment #1)
> we agreed that the way to go here was to only compare the list of built-in
> addon IDs to the blocklist when either the blocklist or the addons db
> changed, which could all be done async after startup.

To be clear, not just built-in add-on IDs, but all add-ons. And not just IDs.
We currently check all blocklistable props against all blocklist entries any
time someone accesses the blocklistStatus property of any add-on. Which
happens a lot.

	Kris Maglione [:kmag] Reporter
	Comment 3 • 7 years ago

As for storing in IndexedDB, it would be nice to store each blocklistable property as a separate index, so we can just query the DB for matching entries when we need to update blocklist status, and then I guess dump entries that need regexp matching in a separate store.

	Robert Helmer [:rhelmer]
	Comment 4 • 7 years ago

(In reply to Kris Maglione [:kmag] from comment #2)
> (In reply to Robert Helmer [:rhelmer] from comment #1)
> > we agreed that the way to go here was to only compare the list of built-in
> > addon IDs to the blocklist when either the blocklist or the addons db
> > changed, which could all be done async after startup.
> 
> To be clear, not just built-in add-on IDs, but all add-ons. And not just IDs.
> We currently check all blocklistable props against all blocklist entries any
> time someone accesses the blocklistStatus property of any add-on. Which
> happens a lot.

Right.. not sure why I wrote "built-in" there.

	Florian Quèze [:florian]
	Comment 5 • 7 years ago

We have changed the goal of this bug enough that I don't think it goes on Mathieu's plate anymore, and from what I remember of our discussion, Kris said he could do it in less than an hour, so I guess he volunteered to take it?