Alex Limi (:limi) — Firefox UX Team Reporter
	Description • 14 years ago

(This is related to bug 522375 & bug 561148)

We currently measure startup time, but we have also had pretty significant shutdown time issues in the past, and while we think most of these have been resolved, we don't have data on how long this actually takes in the wild. It seems like we should track this in a similar way to tracking startup time, since it contributes to Firefox feeling slow/sluggish.

In bug 561148, Marco said: "I suppose one could time from the first shutdown notification to the last bit of the program, we could probably file a bug to track these times."

This is that bug. Implementation left as an exercise to the reader. :P

PS: Couldn't find a bug on this if there is one already.
PPS: I copied the CC list from the startup time bug, I realize that might not be the same set of people interested in this, but I assumed it was better than an empty list.

	Dietrich Ayala (:dietrich)
	Comment 1 • 14 years ago

Cc'ing Alice, who wrote the tshutdown tests (iirc).

	alice nodelman [:alice] [:anode]
	Comment 2 • 14 years ago

The current measurement that we collect for shutdown time is pretty simple.  The browser is opened on a blocking system call which the talos process then waits on.  When a test is complete the browser drops a timestamp using a javascript dump and then closes itself.  Immediately upon the talos wait() completing we take a second timestamp.  Comparing the one from the browser to the one from talos we have the shutdown time.

The advantages of this metric are that we go by when the process is actually no longer around.  This stops the case where you may think that the process has shut down but it is still working in the background.

	Mike Hommey [:glandium]
	Comment 3 • 14 years ago

Note that with bug 552864, this could be made built-in more easily.

	(dormant account)
	Comment 4 • 13 years ago

I posted a naive patch in 666707. This patch tackles time to shutdown, but it can also be extended to report a boolean on whether the browser exited normally like 666707.


Mike what was your suggestion?

	Mike Hommey [:glandium]
	Comment 5 • 13 years ago

I was more thinking of actually measuring the end of the shutdown in main(), after we shutdown XPCOM. The problem is that this can't be tracked with telemetry, then, but anything that measures a significant part of the shutdown will have this problem...

	(dormant account)
	Comment 6 • 13 years ago

(In reply to comment #5)
> I was more thinking of actually measuring the end of the shutdown in main(),
> after we shutdown XPCOM. The problem is that this can't be tracked with
> telemetry, then, but anything that measures a significant part of the
> shutdown will have this problem...

Well as this patch shows, you can save that data and telemetry it on the following startup :)

Note, doing it in main() isn't much better since that's still before a bunch of destructors run(and possibly cause a freeze).

	Mike Hommey [:glandium]
	Comment 7 • 13 years ago

(In reply to comment #6)
> Well as this patch shows, you can save that data and telemetry it on the
> following startup :)
> 
> Note, doing it in main() isn't much better since that's still before a bunch
> of destructors run(and possibly cause a freeze).

After bug 552864, destructors that run after shutdown are very much likely to fail at least on linux, because the libraries are unloaded. So there should really be no such thing left.

	(dormant account)
	Comment 8 • 13 years ago

(In reply to comment #7)
> (In reply to comment #6)
> > Well as this patch shows, you can save that data and telemetry it on the
> > following startup :)
> > 
> > Note, doing it in main() isn't much better since that's still before a bunch
> > of destructors run(and possibly cause a freeze).
> 
> After bug 552864, destructors that run after shutdown are very much likely
> to fail at least on linux, because the libraries are unloaded. So there
> should really be no such thing left.

That's true, but I wouldn't rely on that unless we had some telemetry to back that up. Ie if the firefox executable gets linked to some library that has destructors.