Bugzilla

Bottom-line, I think this bug may not be isn't super actionable; it appears that the key things resulting in >half-second new window operations seem to be other work that happened to be scheduled at the same time, due to bad luck (whether favicon updates, sync operations, or pending GC work that got flushed (possibly GC'ing for the memory increases that I observed in bug 1849393 comment 14).

Beyond those, there's not a particularly massive difference between new-window times for a fresh profile vs. my regular browsing profile (times in the neighborhood of 150-300ms).  So unless there's a way (and enough motivation) to somehow preemmpt/prevent any pending unrelated tasks, in the service of making Ctrl+N fast, there's maybe not a lot we can do here (aside from making the background tasks themselves less expensive).

Not sure whether to resolve as INVALID, or reclassify as S4, or something else. I'll defer to mconley/dmose regarding what (if anything) would be useful to do with this bug.

Bottom-line, I think this bug may not be super actionable; it appears that the key things resulting in >half-second new window operations seem to be other work that happened to be scheduled at the same time, due to bad luck (whether favicon updates, sync operations, or pending GC work that got flushed (possibly GC'ing for the memory increases that I observed in bug 1849393 comment 14).

Beyond those, there's not a particularly massive difference between new-window times for a fresh profile vs. my regular browsing profile (times in the neighborhood of 150-300ms).  So unless there's a way (and enough motivation) to somehow preemmpt/prevent any pending unrelated tasks, in the service of making Ctrl+N fast, there's maybe not a lot we can do here (aside from making the background tasks themselves less expensive).

Not sure whether to resolve as INVALID, or reclassify as S4, or something else. I'll defer to mconley/dmose regarding what (if anything) would be useful to do with this bug.