1363384 - nsZipArchive::GetDataOffset is expensive during startup

Status: RESOLVED DUPLICATE of bug 1373708

(Core :: Networking: JAR, defect, P2)

Description

[Florian Quèze [:florian]]

This profile captured on the quantum reference hardware shows 69ms spent there during startup: https://perfht.ml/2qNJcS9

Comment 1

[Florian Quèze [:florian]]

Actually, it's not just during startup. Here is a profile where it's 276ms / 44% of the time spent between when clicking the "X" icon in the top right corner of the window, and when the confirmation prompt appears: https://perfht.ml/2qONdpq

Comment 2

[(no longer active)]

(In reply to Florian Quèze [:florian] [:flo] from comment #1)
> Actually, it's not just during startup. Here is a profile where it's 276ms /
> 44% of the time spent between when clicking the "X" icon in the top right
> corner of the window, and when the confirmation prompt appears:
> https://perfht.ml/2qONdpq

This is a tangent for this bug, but which build is this from?  Is this Nightly or some local build?

It looks like you are coming from <https://searchfox.org/mozilla-central/rev/224cc663d54085994a4871ef464b7662e0721e83/js/xpconnect/loader/mozJSComponentLoader.cpp#797>.  This implies that you don't have a startup cache, because of this condition: <https://searchfox.org/mozilla-central/rev/224cc663d54085994a4871ef464b7662e0721e83/js/xpconnect/loader/mozJSComponentLoader.cpp#686>.  See bug 1351071 comment 24.  I wonder if this is happening to you?

Comment 3

[Florian Quèze [:florian]]

(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #2)
> (In reply to Florian Quèze [:florian] [:flo] from comment #1)
> > Actually, it's not just during startup. Here is a profile where it's 276ms /
> > 44% of the time spent between when clicking the "X" icon in the top right
> > corner of the window, and when the confirmation prompt appears:
> > https://perfht.ml/2qONdpq
> 
> This is a tangent for this bug, but which build is this from?  Is this
> Nightly or some local build?

It's a Nightly.

Comment 4

[Honza Bambas (:mayhemer)]

Jason, do you know about anyone who could take this?

Comment 5

[(no longer active)]

Note that these are in fact 2 bugs (comment 1 and comment 2)

Comment 6

[(no longer active)]

Err, comment 0 and comment 1.  :-)

Comment 7

[Andrew Overholt [:overholt]]

Startup main thread IO = p1

Comment 8

[(no longer active)]

I'm talking to Jason and Patrick about this on a private email thread.  Needinfoing myself to remember to send a reminder...

Comment 9

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

What was the result of that email thread?

Comment 10

[(no longer active)]

I've yet to hear back.

Comment 11

[Florian Quèze [:florian]]

Another startup profile where this takes more than 300ms: https://perfht.ml/2tAdjgA (captured on today's nightly)

Comment 12

[Firefox Bug Husbandry Bot]

Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 13

[Jason Duell]

This smells like it's part of our general JAR channel main I/O issues.  So it will hopefully be fixed at the same time.  Keeping open until we know if that's the case.

Comment 14

[Jason Duell]

Gary, will this bug get fixed as part of bug 1373708?

Comment 15

[Gary Chen [:xeonchen]]

(In reply to Jason Duell [:jduell] (needinfo me) from comment #14)
> Gary, will this bug get fixed as part of bug 1373708?

It's |nsJARChannel::CreateJarInput| within |nsJARChannel::AsyncOpen|, so I think the answer is yes.