Tag Tracking+ API efficiency note dump

[marcustyphoon]

currently, with a single tumblr tab in steady state, each tag is updated every [number of tracked tags * 30 seconds]. with n tabs, this is also true, but we do n times too many api requests. also, if a tab is inactive, we really don't need to do any api requests on it until the user focuses it again (though we must then refresh any we skipped).

to keep the same cycle but not fetch when tab is inactive: if tab is inactive when query would happen, add it to a set; when tab becomes active, clear set and interval, query everything in set with 1s cadence, then start 30s interval.

to use storage to coordinate between tabs: save unreadCounts: record<tag, count> to storage; make onStorageChanged use unreadCounts to update unreadCountElement; make unreadCountElement hidden initially. then:

let timer;

const refreshCount = (tag, isFirstRun = false) => {
  const { [lastRefreshStorageKey]: lastRefresh = 0 } = await browser.storage.local.get(lastRefreshStorageKey));
  const now = Date.now();
  const lastTimeThisTabTriedToRefresh = timer;
  timer = now;

  if (isFirstRun === false && lastTimeThisTabTriedToRefresh !== undefined) {
    const anotherTabDidRefresh = lastRefresh > lastTimeThisTabTriedToRefresh;
    if (anotherTabDidRefresh) {
      // if another tab did a fetch while we were waiting, let it be the one in control (until it's closed).
      return;
    }
  }

  // this tab is now the one in control; do fetch and save to storage
  await browser.storage.local.set({ [lastRefreshStorageKey]: now });
  /* do fetch; save to unreadCounts */
  /* unhide unreadCountElement */
  }
}

although... note that different tabs could have different tracked tags if they're different accounts. I guess you would have to do...

let lastRefreshes;

const refreshCount = (tag, isFirstRun = false) => {
  const { [lastRefreshesStorageKey]: storedLastRefreshes = {} } = await browser.storage.local.get(lastRefreshesStorageKey));
  const storedLastRefresh = storedLastRefreshes[tag] ?? 0;
  const lastRefresh = lastRefreshes[tag] ?? Infinity;

  const anotherTabRefreshedThisTag = storedLastRefresh > lastRefresh;

  const now = Date.now();
  lastRefreshes[tag] = now;

  if (isFirstRun === false && anotherTabRefreshedThisTag) {
    // another tab did a fetch while we were waiting; let it be the one in charge of updating this tag.
    return;
  }

  // this tab is now in charge of updating this tag.
  await browser.storage.local.set({ [lastRefreshStorageKey]: now });
  /* do fetch; save to unreadCounts */
  /* unhide unreadCountElement */
}

a possibly more logical (but possibly not!) way would be doing a refresh cycle like, I dunno, "every 30 seconds, update the tracked tag that is older than 30 seconds out of date and has gone the longest without a refresh." well—not that, because then multiple tabs would increase api load and get closer to—hold on.

see, initially I had assumed something vaguely like "make sure every tag is no more than a minute out of date" was equivalent to the current behavior, but it absolutely isn't (track 100 tags and they'll be 25 minutes(!) out of date on average with current code). I quickly realized that wasn't even close to the case, but most of my thoughts about how to make n tabs behave the same as 1 tab were doing something of the sort.

of course, you could do "make sure every tag is no more than [number of tracked tags * 30 seconds] out of date" pretty easily, which would yield the same api requests per second figure as the current code. in the case where you track 100 tags, that would mean waiting 25 minutes, then firing 100 api requests one-per-few-seconds, repeat. this is certainly not the same thing as the current behavior but it's not, like... crazy? (maybe put some bounds on the interval, I dunno. 1 minute-10 minutes?)

[AprilSylph]

I've been thinking about this too... my own much less detailed thought dump:

• Can't use storage.session for this because it can't be used in Firefox content scripts—yet. Something to keep an eye on.
• sessionStorage is a nonstarter as an alternative because it's partitioned by tab. Ugh.
• Unread counts being visible and out of date on pageload is, in my opinion, fine. Just as long as we are going to be refreshing them afterwards.
• I bet there's at least one person out there whose workflow for Tag Tracking+ is to open a Tumblr tab, read their unread tags, then switch to a completely different website while waiting for their unread counts to tick up. Doing no fetches at all while there are no active Tumblr tabs will annoy this person. I'm not saying that that's a good reason not to pursue this.

[AprilSylph]

• I think the quickest and easiest win here would be to, while changing nothing else, just refuse to fetch a tag if the current tab isn't active.

[marcustyphoon]

That would make the counts in a tab suuuuper out of date. Would look weird next to a newly opened tab with new counts.

[marcustyphoon]

Unread counts being visible and out of date on pageload is, in my opinion, fine.

I was thinking it would be annoying if you had the option to hide zero-count on. But I guess the cached count can't really be too high, just too low.

I bet there's at least one person out there whose workflow for Tag Tracking+ is to open a Tumblr tab, read their unread tags, then switch to a completely different website while waiting for their unread counts to tick up. Doing no fetches at all while there are no active Tumblr tabs will annoy this person. I'm not saying that that's a good reason not to pursue this.

True. One thing I didn't get down is that making tabs coordinate makes the background tab case less of a big deal. We could certainly make a long delay before it kicks in.

[marcustyphoon]

master...marcustyphoon:XKit-Rewritten:tag-tracking-coordinate-tabs-1

Well, that was a fun test of whether I can write code in my head. Answer: ehhh, kind of. I'd forgotten a few things and there were some pretty major typos in the part I had written out.

(Anyway, eh, maybe this tab coordination MVP functions. Kind of hard to tell, tbh.)