1741608 - Firefox reads all the fonts after startup and it slows everything down, related to slow DirectWrite performance

Status: RESOLVED DUPLICATE of bug 1688951

(Core :: Layout: Text and Fonts, defect)

Description

[assagai]

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

Steps to reproduce:

open any web page (doesn't matter which)

Actual results:

all pages load for a long time
the problem persists even after all extensions are disabled and cash is cleared

Expected results:

on previous release, the same pages loaded much faster

Comment 1

[Hani Yacoub, Desktop QA]

Are you facing this issue only on firefox 91.3.0esr? Is this also reproducible on Firefox 94?
Thanks.

Comment 2

[assagai]

haven't tried Firefox 94
the reason for esr was support for certain plugins

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 4

[Hani Yacoub, Desktop QA]

Are you saying that after disabling some certain plugin the issue was not reproducible anymore? Could you please tell us what plugin cause the problem?
Thanks.

Comment 5

[assagai]

no, I've explained why I've been using esr instead of the latest release (Firefox 94). the reason was that some plugins did not work on the latest release.
these plugins have no bearing on the performance of the browser. since the last update, it's very slow (with or without plugins)
I had to partially shift to chrome since it has become so inconvenient to use
the only thing that changed for me was the last major update.

Comment 6

[Denis Palmeiro [:denispal]]

Hi assagai,

If you are still experiencing this problem, could you please provide a performance profile of the problem. You can find some instructions on how to do this here https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html.

Thank you!

Comment 7

[assagai]

performance profile is uploaded https://share.firefox.dev/3nPQHVg

Comment 8

[Markus Stange [:mstange]]

Thanks for the profile! The slowdown seems to happen when we're reading font data.

Do you have a lot of fonts installed? Or some fonts which are just very big files?

Profile with better dwrite symbols (working around bug 1751571): https://share.firefox.dev/3GRHV0s

Comment 9

[assagai]

I did not install any fonts on purpose. All of the fonts were standard fonts or installed along with other programs
250 fonts in total, the biggest is 38 Mb
The argument does not hold water:
The problem occurs periodically regardless of the page (mostly on Firefox startup)
Same page may open promptly
Chrome opens same pages in a fraction of a second even if it takes firefox 10-15 mins to process the page

Comment 10

[Markus Stange [:mstange]]

Oh I fully agree that it's Firefox's fault. But it does definitely have to do something with fonts. Firefox reads font information for all fonts on the system shortly after startup, and the profile shows that that's what's slowing down everything. Chrome might not be reading these fonts, or it might be doing so on another thread.
This font reading is intended to only last a few seconds at most; clearly Firefox is doing something wrong and unintended here.

Comment 11

[assagai]

OK, what do you suggest I do? I cannot possibly uninstall fonts one by one and see if the problem goes away.
I can send you more information if you tell me what you need.

Comment 12

[Sean Feng [:sefeng211]]

Markus, I think there's probably no easy solution to fix it since that's how Firefox works at the moment, just double check to see if you have a suggestion for the reporter?

Comment 13

[Markus Stange [:mstange]]

I'm not sure; Jonathan, do you have any suggestions?

Comment 14

[Jonathan Kew [:jfkthame]]

It seems like for some reason DirectWrite's font access is incredibly slow on the reporter's machine, but I have no idea why that might be. Could some kind of interaction with an antivirus or similar product be involved?

assagai, could you please attach the about:support information from your system, so we can get a better idea of the configuration involved? The behavior you're seeing is not at all typical or expected, so we need to figure out what is causing it to be so bad for you.

Comment 15

[assagai]

Attachment: Troubleshooting information

I don't see an option to atach a file, so here is the text:

Comment 16

[assagai]

here is the text from about:support

Comment 17

[Jonathan Kew [:jfkthame]]

What type/speed of CPU and how much RAM does your machine have? I wonder if it is struggling to run Firefox with Fission enabled, and DirectWrite is suffering from lack of resources.

If you go to about:support and set fission.autostart to false, and then quit and restart the browser, does that make a difference?

Markus, any other ideas? I don't have a Win7 machine to compare at all, but the slow DirectWrite performance the reporter is seeing seems very extreme. Do you have access to any Win7 systems to compare how they behave?

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 19

[Boris Chiou [:boris]]

Hi assagai,

Would you mind checking comment 17? Thanks.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jfkthame, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 21

[Jonathan Kew [:jfkthame]]

Markus, do you have any ideas for how we can investigate this further? Could it be that the system just doesn't have sufficient resources to run Firefox well? Unfortunately, I haven't seen any response to the questions in comment 17.

Comment 22

[Smythe Bacchus]

I've been experiencing the exact same symptoms as the reporter. On first run after boot, Firefox hangs on reloading of the previous session for many minutes (I'm patient). During this time there is heavy HDD activity from Firefox (I have a mechanical HDD).

I have seven windows and 86 tabs, but five of these windows have about:blank as the active tab, so only two windows are actually reloading a webpage on Firefox startup. After the session has loaded, I can exit and restart the same session in seconds.

I tried the suggestion in comment 17, and set set fission.autostart to false and rebooted my system. On first run after boot, Firefox reopened the previous session in seconds. My laptop is a HP 6710b with Intel 965 Express graphics running Win10 21H2 x64.

I've been searching for a solution for around 9 to 12 months, uninstalling add-ons, trying other setting changes etc. and this actually seems to fix it. I suspected this was a regression in Firefox caused by an "improvement" that was only tested on fast PCs.

Comment 23

[Markus Stange [:mstange]]

Smythe, see comment 6 - could you attach a performance profile?

Comment 24

[Smythe Bacchus]

Sorry Markus, I have not been able to consistently reproduce this issue and fission.autostart is back to true. It still happens sometimes, but I will immediately quit Firefox, wait for disk activity to stop and restart Firefox which seems to bypass the issue.

One significant change I have made to is to disable all message signaled interrupts using a utility called MSI Tool. This has improved stability and performance of my old HP 6710b (Win 10, crash IRQL_NOT_LESS_OR_EQUAL) and HP 6560b (Win 11, constantly I/O bound on boot).

IMO running Win 10/11 64bit with outdated h/w should have MSI disabled. Mixing IRQ and MSI driver interrupt modes seems to be the problem. All my drivers are now set to IRQ mode only.

Comment 25

[Daniel Holbert [:dholbert]]

jfkthame, should we dupe this to bug 1688951?

Comment 26

[Jonathan Kew [:jfkthame]]

I guess we may as well dupe it, yes. I think in all these cases, the underlying issue is that DirectWrite is deciding it needs to completely rebuild its internal database, or something like that, and this blocks for a long time (especially on older/less-powerful systems, or if the browser is busy trying to restore lots of tabs at the same time, and between that and DWrite's access to all the fonts, disk i/o is completely bottlenecked).

Comment 24 is interesting:

It still happens sometimes, but I will immediately quit Firefox, wait for disk activity to stop and restart Firefox which seems to bypass the issue.

This sounds like a DWrite re-initialization (whatever that is, exactly) has been triggered, and continues (at a system level) after Firefox exits; once it is complete, things work smoothly, but attempting to use Firefox while it's going on is just painful. (I wonder if Fission makes it worse due to lots of processes touching DWrite, and maybe setting off multiple parallel attempts to reinitialize it?)