Closed Bug 1763839 Opened 2 years ago Closed 2 years ago

Firefox even in safemode no addon's uses 15% cpu while doing nothing since update 99.0 (used less then 3% on previous update).

Categories

(Firefox :: Session Restore, defect)

Firefox 99
defect

Tracking

()

RESOLVED DUPLICATE of bug 1763451

People

(Reporter: gamesonlymail, Unassigned)

References

Details

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

Steps to reproduce:

ran help troubleshoot loaded with no ext or add ons. still using 15% cpu with no webpage loaded just one single tab.

Actual results:

the same 13 to 15 % cpu used with nothing running but firefox and one tab with no webpage loaded.

Expected results:

cpu percent should of been less then 3% like with previous update 89.

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

Component: Untriaged → Performance
Product: Firefox → Core

FWIW I am seeing the same on Windows 11, 99.0.1 - have had to revert to 98 and stop automatic updates. Found a Reddit thread that sounded the same, and also on Linux.

(In reply to u704910 from comment #2)

FWIW I am seeing the same on Windows 11, 99.0.1 - have had to revert to 98 and stop automatic updates. Found a Reddit thread that sounded the same, and also on Linux.

Did Downgrading solve your issue?

Could you create a performance profile using https://profiler.firefox.com/ and share the link to the uploaded profile here?

Flags: needinfo?(gamesonlymail)

(In reply to Olli Pettay [:smaug] from comment #4)

Could you create a performance profile using https://profiler.firefox.com/ and share the link to the uploaded profile here?

do you want this link posted here for all to see ?

Flags: needinfo?(gamesonlymail)

If possible yes. But if you think it has some private information, you can limit that when clicking "upload local profile" button

(In reply to Olli Pettay [:smaug] from comment #6)

If possible yes. But if you think it has some private information, you can limit that when clicking "upload local profile" button

https://share.firefox.dev/3KdV6cF this is running idle no activity 1 tab open blank for 2 mins . you did not specify how long to run the profiler.. this is running normal with all addons, but i can run another one in troubleshoot mode if you like.. Either has the same effect stays around 15 to 20 % cpu usage never releases it. also in task manager it's always saying power usage high(if that matters or not). this started with version 99. i have not cleared or run a reset yet.

Thanks! The profile points at this code in SessionSaver.jsm:

      let saveStateAsyncWhenIdle = deadline => {
        // When looking at the telemetry data, the time it takes to execute
        // _saveStateAsync is around 5.9ms (median). Therefore,
        // we'll not execute the function when the idle time is less than 5ms.
        if (deadline.timeRemaining() < 5) {
          this._idleCallbackID = requestIdleCallback(saveStateAsyncWhenIdle);
          return;
        }
        this._saveStateAsync();
      };

On systems with less than 5ms of idle time, e.g. on systems with high monitor refresh rates, it seems like this would just reschedule itself endlessly and never do any work, all the while keeping the CPU 100% busy. Maybe it is able to do work once all animations stop.

That code has been around since 2017 though, it was added by bug 1388664. sg1sg1, did you recently get a new monitor or switch monitor refresh rates?

Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Markus Stange [:mstange] from comment #8)

Thanks! The profile points at this code in SessionSaver.jsm:

      let saveStateAsyncWhenIdle = deadline => {
        // When looking at the telemetry data, the time it takes to execute
        // _saveStateAsync is around 5.9ms (median). Therefore,
        // we'll not execute the function when the idle time is less than 5ms.
        if (deadline.timeRemaining() < 5) {
          this._idleCallbackID = requestIdleCallback(saveStateAsyncWhenIdle);
          return;
        }
        this._saveStateAsync();
      };

On systems with less than 5ms of idle time, e.g. on systems with high monitor refresh rates, it seems like this would just reschedule itself endlessly and never do any work, all the while keeping the CPU 100% busy. Maybe it is able to do work once all animations stop.

That code has been around since 2017 though, it was added by bug 1388664. sg1sg1, did you recently get a new monitor or switch monitor refresh rates?

NO monitor is almost 3 years old i do have the refresh rate set to 240hz but it was set to that in version 98 firefox with no cpu idle time above 3% i can try adjusting the refresh rate to see if still does the same thing. what refresh rate would you like it set to?..

Hello,

I confirm having problem since 99.0 on Windows 10 1909.

I do have 240hz monitor. I also have timeBeginPeriod(1) set in system, if it is relevant (more on this here https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod).

Downgraded to 98.0 for now, and I confirm that there is no issue in 98.0, on the same system (240hz, etc).

On 99.0, when I do nothing, I see one thread always maxed out by firefox (100% of one core, which is reported as 6.25% of cpu on 16 threaded 9900k), and it noticeably affects overall system performance. Looked to the call stack of this thread by Process Hacker, and it only showed various Idle and WaitFor functions, i.e. no actual work, which somewhat coincides with the code snippet above.

This cpu load disappears when I'm loading some page. Once it is loaded and nothing happens - one thread is getting maxed out again.

Thank you and hope this helps.

That's interesting.

Is this reproducible for you on a fresh profile? Could you try to find a regression range using mozregression?

Flags: needinfo?(gamesonlymail)

(In reply to Markus Stange [:mstange] from comment #11)

That's interesting.

Is this reproducible for you on a fresh profile? Could you try to find a regression range using mozregression?

i haven't used a fresh profile.. i would need to backup my currant one and be able to restore it later.. what is the purpose of regression range and does this show identifiable information.

Flags: needinfo?(gamesonlymail)

The purpose of a regression range is to find out which change introduced the bug. The mozregression tool asks you to test many different builds in order to make the window between "working" and "broken" builds as small as possible. The regression range does not include identifiable information.

(In reply to Markus Stange [:mstange] from comment #13)

The purpose of a regression range is to find out which change introduced the bug. The mozregression tool asks you to test many different builds in order to make the window between "working" and "broken" builds as small as possible. The regression range does not include identifiable information.

I don't know the procedure here.. but with the release of version 100 of firefox my issue is no longer present, so it must have been fixed now when you go to a website and it loads it releases the cpu cycle like normal. so i believe this issue no longer needs resolving. thanks for all the help and appreciate you guys hard work.

Excellent! Thanks for reporting back.

(In reply to Markus Stange [:mstange] from comment #8)

Thanks! The profile points at this code in SessionSaver.jsm:

      let saveStateAsyncWhenIdle = deadline => {
        // When looking at the telemetry data, the time it takes to execute
        // _saveStateAsync is around 5.9ms (median). Therefore,
        // we'll not execute the function when the idle time is less than 5ms.
        if (deadline.timeRemaining() < 5) {
          this._idleCallbackID = requestIdleCallback(saveStateAsyncWhenIdle);
          return;
        }
        this._saveStateAsync();
      };

On systems with less than 5ms of idle time, e.g. on systems with high monitor refresh rates, it seems like this would just reschedule itself endlessly and never do any work, all the while keeping the CPU 100% busy. Maybe it is able to do work once all animations stop.

That code has been around since 2017 though, it was added by bug 1388664.

Olli, how do you feel about this code? Should we do something about it?

Flags: needinfo?(bugs)

Yes. Idle callback isn't guaranteed to run ever, so one would expect there to be some timeout value to run the callback eventually.

Component: Performance → Session Restore
Flags: needinfo?(bugs)
Product: Core → Firefox

Hello,
I've been using version 100.0 for a couple of days now, and I can also report that since version 100.0 the issue is no longer present for me. Thank you very much.

Thank you for testing.
I think we can mark this one as a dup of bug 1763451.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.