Closed Bug 1737848 Opened 3 years ago Closed 2 years ago

Firefox take a really long time (~2 minutes) to load first page after reboot.

Categories

(Core :: Performance, defect, P3)

Product:
Core
Component:
Performance
Version:
Firefox 93
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1567863

People

(Reporter: Steve_Davis, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Open Firefox after a reboot and try to load a web page.

Actual results:

When I first start Firefox after a computer reboot it opens quickly, but takes about 2 minutes to load the first page. During that time the hard drive is maxed out and the entire computer slows. Once the ~2 minutes passes, everything else loads and runs quickly.

I've tried safe mode and removing all add-ons but that does not help. I have had this issue for years and the only fix in the past has been to refresh my profile. However, over time the issue gradually reappears.

I've created a profile and see that the slowdown seems to be happening on "ntwaitformultipleobjects ntdll.dll":

https://share.firefox.dev/2ZqWw25

Expected results:

First page loads in less time.

Component: Untriaged → Performance
Product: Firefox → Core

Hi Steve,

Would you be able to redo the profile but with more threads enabled? To do this, click on the "Edit Settings" link on the profiler addon and then enter an asterisk (*) in the box that says "Add custom threads by Name:", and reprofile the startup again. That would be very helpful in identifying what the parent process is waiting on.

Thank you!

Flags: needinfo?(Steve_Davis)

Hi Denis,

Yes, I can redo with more threads when I get back home next week.

Thanks
Steve

I've edited the settings and uploaded a new profile:

https://share.firefox.dev/30sK0A1

Thanks
Steve

Flags: needinfo?(Steve_Davis)

Checking to see if any more information is needed.

Thanks

Flags: needinfo?(plawless)

Steve, I see the initial request took a long time for Waiting for the socket thread and I don't see the socket thread was being profiled. Could you please recollect another profile with the socket thread selected this time?

Flags: needinfo?(plawless) → needinfo?(Steve_Davis)

(In reply to Sean Feng [:sefeng] from comment #5)

Steve, I see the initial request took a long time for Waiting for the socket thread and I don't see the socket thread was being profiled. Could you please recollect another profile with the socket thread selected this time?

Will do. I will need to do it tomorrow as Firefox seems to generally start up much faster on subsequent loads each day. The first startup is always slow, but even after a reboot, it usually works better for the rest of the day. I am not sure if that is a hint into what is going on.

All threads are now check and the "Add Custom Threads by Name" field shows this:

GeckoMain,Compositor,DOM Worker,Renderer,RenderBackend,PaintWorker,StyleThread,Socket Thread,StreamTrans,ImgDecoder,DNS Resolver,TaskController

For the previous profile I had an asterisk in that field which enabled the "Bypass selections above and record all registered threads" checkbox automatically. Do you have a sample of how the entire "Threads" section should look?

Thanks

oh, actually I think asterisk worked last time. There are some threads that were not shown in the profile by default. I am now able to see Socket Process, however, it looks it was just idle.

I noticed ExtensionParent - uBlock0@raymondhill.net, api_event: webRequest.onBeforeRequest in the profile, can you try to disable ublock to see if it changes anything?

I did try disabling all extensions in the past to no avail, but that over a year and many versions ago. I will disable them again at the end of the day so that when I run the profile at startup tomorrow they will not be there.

FYI, the last two mornings (once with all extensions disabled and once with them enabled) Firefox started up as was responsive fairly quickly (an unusual good streak). I will post again when I get more data I can share.

Duplicate of bug 1567863?

If you can provide more feedback here if you see this again and perhaps even a new performance profile in that case, that would be great.
But if you can't see this anymore, feel free to close as worksforme.

Severity: -- → S3
Priority: -- → P3

I have been having hardware with my main computer that shows the issue and haven't been able to test on it recently. If no one else is having this problem, this issue can be closed as it appears it may be specific to my setup. It does not happen on my laptop.

Thanks

Flags: needinfo?(Steve_Davis)

Thanks Steve, feel free to reopen the bug if it reappears.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME

Another slowdown this morning after 96.0.3 was applied and the browser restarted. I was able to create a new profile, but with all extensions enabled. It appears uBlock Origin may be effecting the startup time as it has started normally with that disabled the few times I tried.

https://share.firefox.dev/3g7c93O

Steve, we have a guess that this might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1567863#c70. Can you go to the profiler setting and check Main Thread File IO, and then collect a profile again when this issue reappears?

And yeah, In your profile, uBlock Origin indeed did somethings that slowed Firefox down.

I just created another profile with Main Thread File IO enabled. This one only took about 20 seconds to load... not sure if it will give you the required info.

https://share.firefox.dev/3g8FY3O

Thanks
Steve

Thanks, this is very helpful. Looks like the guess was correct, you were also blocked by slow disk IO.

There are some workarounds mentioned in here, you might want to try that.

In the meantime, I am going to set this bug as a duplicate.

Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.