1910782 - Expose something like a Services.startup.startTime for easier use from browser JS

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Sam Foster [:sfoster] (he/him)]

Currently, to get a timestamp for when the browser started, we have to call Services.startup.getStartupInfo().start.getTime(). This is presumably a constant integer value which shouldn't need to be re-allocated and calculated each time its needed. Either caching the startup info (which presumably also doesn't change) or exposing a Services.startup.startTime to get just the integer we need would be both handy and faster in some cases.

See bug 1882655 where we needed to cache the value to fix a perf regression caused by accessing this value for each open tab.

Comment 1

[JL]

I can try taking a stab at this if possible?

I see 3 instances of Services.startup.getStartupInfo().start.getTime() in the code including the one I added in bug 1882655, is the idea to have only one call for all 3?

or are we thinking of getting rid of Services.startup.GetStartupInfo().start.getTime() altogether?

in approach #1 we would want to put the cache version of the startup time in a file that can pass the value to browser/component/content/tabs.js
browser/components/tabbrowser/test/browser/tabs/browser_lastSeenActive and browser/modules/laterRun.sys.mjs

since they're in different folder hierarchies I'm not 100% sure I know where the best place for it would be (as it seems that Services is what helps share information between files? I'm assuming a lot here so if I'm wrong please let me know)

approach #2 would mean modifying Services.startup so that it has a property with the timestamp that gets generated when the browser starts, I'm having trouble figuring out where Services comes from, I don't know which file has the definition of startup where I could add a property with the timestamp.

Comment 2

[Sam Foster [:sfoster] (he/him)]

(In reply to JL from comment #1)

I see 3 instances of Services.startup.getStartupInfo().start.getTime() in the code including the one I added in bug 1882655, is the idea to have only one call for all 3?
or are we thinking of getting rid of Services.startup.GetStartupInfo().start.getTime() altogether?

I'm not the right person to answer this question. :mossop can you advise?

Comment 3

[Dave Townsend [:mossop]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #0)

Currently, to get a timestamp for when the browser started, we have to call Services.startup.getStartupInfo().start.getTime(). This is presumably a constant integer value which shouldn't need to be re-allocated and calculated each time its needed. Either caching the startup info (which presumably also doesn't change) or exposing a Services.startup.startTime to get just the integer we need would be both handy and faster in some cases.

You say "just the integer we need" but different bits of code get different integers from the startupinfo. The start time is actually used less than the process time is but I don't want to add a new property for every possible time that people might want. So I guess we would probably add a Services.startup.getStartupTime(event) function that returned a simple timestamp. I'm not completely convinced that it's worth the trouble though. How much do we envision needing this in other code in the future?

Comment 4

[Sam Foster [:sfoster] (he/him)]

(In reply to Dave Townsend [:mossop] from comment #3)

I'm not completely convinced that it's worth the trouble though. How much do we envision needing this in other code in the future?

Right, I think that's a fair question. We have the per-window (per tab-container) cached value of the startup time. So we recalculate it each time a window is opened. That's a bit redundant but probably doesn't amount to much of a cost in that context. Poking around in searchfox shows a handful of callers. There's another instance in TelemetryFeed where each instance makes the same call for this value. A similar case in AboutNewTab. I filed the bug because I saw this redundancy but was not sure of the level of effort to fix it and maintain the fix, or if this meets the threshold of a problem that needs fixing. If you think this is optimization for its own sake I'm happy with a WONTFIX.

Comment 5

[Dave Townsend [:mossop]]

I think unless we find a case that isn't trivially solved with some local caching then I'd rather not add a second method to access this data.