Not sure, but innerHTML seems to be taking a long time, in a call that loops over the results of getElementsByName. Given that getElementsByName doesn't return a real array, is it possible internally it's doing bookkeeping to make sure the iteration is still over the same set of nodes? Or alternatively maybe modifying innerHTML is just slow.

Not an answer exactly, but I did some work with large HTML tables for an analytics project, and I did learn browsers struggle with larger tables.

After doing a number of optimizations, our 2000 row table took 1.2 seconds for chrome to insert the elements (purely the appendChild call). That was down from around 2.6 before trimming down the HTML.

Works fine for me on an average laptop with latest stable Firefox.

Try "Show All".

Seems instantaneous on Firefox for me.

Really?! It isn't instantaneous for me, even on Firefox 62 (Windows). Takes some half a second or so.

I'm on Firefox 68.0.2 on Windows 10.

I can click "Show All" and "Hide All" over and over and there is hardly any delay. Maybe you should upgrade to the latest and see if it makes a difference.

Interesting, thanks for mentioning this! It seems to be something with my profile, because a fresh profile is also definitely faster (maybe 200-300ms just eyeballing). The latest unbranded build I got [1] also seems about the same if not faster (maybe around 200ms). Definitely not "instantaneous", but I'll definitely track this down.

UPDATE: At least 3 of the culprits seem to be MutationObservers from my own extensions (as in, from extensions that I have written for myself) that have {childList: true, subtree: true}! I guess I will have to optimize them. :-)

[1] https://queue.taskcluster.net/v1/task/Uht_zkkPThu384OAHNPwdA...

200ms on Firefox clicking show all.

Tables layout is generally complex and slow, only hiding the text with CSS feels very fast.

Once layout is involved even without looping to set innerHTML it becomes a lot slower.