(leaving needinfo for the reporter because it's always possible that they're seeing something different from Sergiu) (In reply to Negritas Sergiu, Desktop QA from comment #5) > Here is a link to the performance profile: > > https://share.firefox.dev/3ZHiOc9 Focusing in on the download time, https://share.firefox.dev/4kQiPDd , I don't really see anything in the frontend that is obviously responsible for the CPU use. In fact, the profile suggests that the CPU use is not that bad (certainly not consistently close to 100%), but `about:processes` in the screenshots shows that the CPU use _is_ that bad. I don't know why they're disagreeing, or how to find out where the "spare" bit of CPU is going - or if I'm missing some kind of smoking gun in the profile. Ni Florian for some pointers based on this profile... The only real thing I see in the profile is vsync etc. for the compositor, so I assume this is the download animation, which AIUI we'd previously optimized? So I don't know if that's regressed on the layout side (AFAIK nothing significant has changed on the frontend side but I could be wrong about this). Sergiu: could you check if esr115 or older behaved any better) ?
Bug 1972941 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(leaving needinfo for the reporter because it's always possible that they're seeing something different from Sergiu) (In reply to Negritas Sergiu, Desktop QA from comment #5) > Here is a link to the performance profile: > > https://share.firefox.dev/3ZHiOc9 Focusing in on the download time, https://share.firefox.dev/4kQiPDd , I don't really see anything in the frontend that is obviously responsible for the CPU use (vast majority of samples on the parent proc main thread are in `poll()` on the event loop). In fact, the profile suggests that the CPU use is not that bad (certainly not consistently close to 100%), but `about:processes` in the screenshots shows that the CPU use _is_ that bad. I don't know why they're disagreeing, or how to find out where the "spare" bit of CPU is going - or if I'm missing some kind of smoking gun in the profile. Ni Florian for some pointers based on this profile... The only real thing I see in the profile is vsync etc. for the compositor, so I assume this is the download animation, which AIUI we'd previously optimized? So I don't know if that's regressed on the layout side (AFAIK nothing significant has changed on the frontend side but I could be wrong about this). Sergiu: could you check if esr115 or older behaved any better) ?
(leaving needinfo for the reporter because it's always possible that they're seeing something different from Sergiu) (In reply to Negritas Sergiu, Desktop QA from comment #5) > Here is a link to the performance profile: > > https://share.firefox.dev/3ZHiOc9 Focusing in on the download time, https://share.firefox.dev/4kQiPDd , I don't really see anything in the frontend that is obviously responsible for the CPU use (vast majority of samples on the parent proc main thread are in `poll()` on the event loop). In fact, the profile suggests that the CPU use is not that bad (certainly not consistently close to 100%), but `about:processes` in the screenshots shows that the CPU use _is_ that bad. I don't know why they're disagreeing, or how to find out where the "spare" bit of CPU is going - or if I'm missing some kind of smoking gun in the profile. Ni Florian for some pointers based on this profile... The only real thing I see in the profile is vsync etc. for the compositor, so I assume this is the download animation, which AIUI we'd previously optimized? So I don't know if that's regressed on the layout/graphics side (AFAIK nothing significant has changed on the frontend side but I could be wrong about this). Sergiu: could you check if esr115 or older behaved any better) ?