Startup optimization ideas

[eritbh]

Just a general issue to keep track of some thoughts on improving the speed of toolbox's init processes, spun off from #403. Probably also a good excuse for a general review and cleanup of the init code.

• Use parallel requests for checking moderated subreddits, user information, etc. when toolbox is starting

• Ensure that we're doing as little work as possible at init; generate non-critical stuff as lazily as possible so we don't waste time

• This is a complicated one, but maybe allow modules to "prefetch" resources when toolbox is still initializing, rather than waiting on the init requests before sending more requests (based on screen recordings of init times in queues, this has the potential to cut the time from page load to toolbox being usable in half for stuff like the "show recent actions" queuetools button) (this might be blocked on #248)

[creesch]

Just as a general note as I have been experimenting with this a bunch already, for old reddit specifically it takes a long time for the DOM to be even at the interactive state which is fairly long after reddit is already visible for the user. The ready state is the soonest we can start adding buttons.

There is also the inherit problem that we simply are adding a lot to the DOM after the fact, other than being more careful about item placement to prevent height redraw there we still can only start looking for elements when the page is there and only after that start adding stuff. The difference is noticeable when you compare old to new reddit, as jsAPI is native to new reddit toolbox shows much less of a delay there as it doesn't need to look for the items.

We also already make sure to only draw buttons visible in the viewport to reduce the amount of interactions needed, but reddits html structure is fairly complex so interacting with the DOM therefore simply takes a bit of time.

There is also some fuckery going on in regards to perception, the way toolbox used to work with applying everything at once and as soon as it was visible actually delayed loading of reddit. So in the past it took longer altogether but it might have felt shorter simply due to toolbox not nicely waiting its turn and just brute forcing itself into the DOM.

Having said all that, if we can make gains I am all in favor.

To respond to your points:

• No brainer, if this helps sure. Note though that in most cases we don't do API requests and draw from cache.
• Sounds like a good idea, though I think it can be a bit of a challenge as coreutils are effectively a base prerequisite for modules to load.
• If we can manage this it would be great, the problem is that often we don't know what is needed until the DOM is processed for items. Show recent actions is a good example there as we don't know for what subs we need to fetch the modlog and we can't reasonably fetch the modlog for all subs someone mods as that either results in more slow down for people with more than a few subs or less items if we go for the combined log.

In regards to the first point, I might have an idea there. If we move tbstorage.js to the document_start section and include getModSubs and getUserDetails in there we can already do those requests when the DOM is still getting ready. I'll experiment with that a bit today to see what that will bring us.

[creesch]

Something I noticed while profiling is that decompressing usernotes is a fairly intensive task. Which makes sense of course, for general performance on page it might help if we actually do this on the background page. The downside there is that we first fetch it, send it to the content_script and then would send it back to the background page. Unless we want to go a bit creative in how we fetch usernotes...

[eritbh]

If we can manage this it would be great, the problem is that often we don't know what is needed until the DOM is processed for items. Show recent actions is a good example there as we don't know for what subs we need to fetch the modlog and we can't reasonably fetch the modlog for all subs someone mods as that either results in more slow down for people with more than a few subs or less items if we go for the combined log.

I was mostly considering /r/sub/about/modqueue and related queues on a specific subreddit for this module. Since the sub is in the URL, its log can be fetched as soon as we know what the current URL is rather than waiting to process the DOM. We could also consider fetching entries directly from /r/mod for the shared queues, though for users modding a large number of subs it becomes unlikely that listing will have anything relevant, and the individual logs would still have to be fetched anyway.

---

The downside there is that we first fetch it, send it to the content_script and then would send it back to the background page.

This is a bit more communication back and forth than optimal, but at least the overhead would be minimal compared to decompressing in the content script. I think it'd be simplest to implement it this way at least for now. I'll spin this out into its own issue since it seems actionable immediately.