1357710 - Uninitializing UITour is expensive

Status: NEW

(Firefox :: Tours, enhancement, P3)

Description

[Florian Quèze [:florian]]

See bug 1349742 where as a stopgap I made UITour skip initialization/uninitialization when the only page even is getConfiguration (this is the common case of loading about:home).

I think we should still consider improving this.


From bug 1349742:

(Florian Quèze [:florian] [:flo] from bug 1349742 comment #0)

> The observer from UITour.jsm is very visible in profiles:
> https://perfht.ml/2noCrEC
> 
> http://searchfox.org/mozilla-central/rev/
> ee7cfd05d7d9f83b017dd54c2052a2ec19cbd48b/browser/components/uitour/UITour.
> jsm#718
> 
> This iterates over all the existing windows, and that loop seems to be O(n2)
> (this landed in bug 1126756).
> 
> This slow code runs when receiving the message-manager-close notification,
> which is fired several times as a result of the tabbrowser
> updateBrowserRemoteness call.

(Matthew N. [:MattN] from bug 1349742 comment #6)

> The reason for the inefficient loop is to find the <browser> associated with
> the message-manager-close. If there is a way to QI to something to get that
> <browser> reference the multiple loops could be replaced. That would help
> for cases where there are real UI tours going on too, not just for cases
> like about:home which only use getConfiguration.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

It's kind of astonishing that we don't seem to have an observer notification for "a browser was destroyed" that works for both e10s and non-e10s. message-manager-close seems like it fires at the appropriate times, but it doesn't pass anything useful.

I hesitate to say it, but perhaps we should fire another observer notification, browser-destroyed, and pass the browser as the subject, to make something like this easier.