1955243 - CPU usage spikes up to 70% while key points are being generated on Link Previews

Status: RESOLVED WONTFIX

(Core :: Machine Learning: Frontend, defect)

Description

[Ciprian Georgiu, Desktop QA]

Found in

• Nightly 138.0a1

Affected versions

• Nightly 138.0a1

Tested platforms

• Affected platforms: Windows 11, Ubuntu 24.04, macOS 14

Preconditions

• Firefox is launched.
• browser.ml.linkPreview.enabled = true

Steps to reproduce

1. Navigate to https://edition.cnn.com/
2. Hover over a link from the page and press the "Alt" key on the keyboard.
3. Check the CPU usage in Task Manager.

Expected result

• CPU usage spikes up to 70% while key points are being generated.

Actual result

• The CPU doesn't experience spikes, or at least not as high, when generating the key points.

Regression range

• Not a regression, as this is a new implementation. The issue reproduces on the first build available (17.03.2025) that includes the Link Preview feature.

Additional notes

• Marking this with the [fidefe-quality-foundation?] keyword, as this could lead to performance issues impacting the overall browser. As such, we consider this a high-impact bug for this feature.
• This is more noticeable on Windows machine.

Comment 1

[Ed Lee :Mardak]

aristide, are there expectations of max cpu usage? given the current link preview interface, it seems like something the user would want to finish quickly, but then again, it also currently allows users to scroll away to read other parts of the page and scrolling smoothness can be highly affected by other loads

Comment 2

[Aristide Tossou]

Questions

• Can you specify the machine specs this bug was observed on? In particular, I am interested in the CPU brand and model, clock speed, available RAM, and any other relevant hardware details. Please precise the number of CPU cores.

• Also, I would like to know if you are able to observe performance issues impacting the overall browser while keypoints are being generated.

• Please also clarify what the reported "70% CPU usage" refers to. For example, on macOS, CPU usage is not normalized to 100%. On a 4-core system, a single process can report up to 400% CPU usage, corresponding to full utilization of all cores.

Background on the feature:
During keypoint generation, it is expected that CPU usage may spike temporarily. The ML engine powering this process is designed to use as much CPU as available in order to complete the task as quickly as possible—without negatively impacting the user's system performance. This behavior is intentional and short-lived. The maximum CPU usage we reach depends on the hardware specifications of the system, not the operating system.

Comment 3

[Ed Lee :Mardak]

potentially using native bug 1959419 instead of wasm, total cpu usage and spike could decrease

Comment 4

[Ciprian Georgiu, Desktop QA]

(In reply to Aristide Tossou from comment #2)

Questions

• Can you specify the machine specs this bug was observed on? In particular, I am interested in the CPU brand and model, clock speed, available RAM, and any other relevant hardware details. Please precise the number of CPU cores.

Here's a copy of the hardware information extracted from Win 11 machine.

Also, I've saved a report from the system using CPU-Z tool. Hope this helps!

• Also, I would like to know if you are able to observe performance issues impacting the overall browser while keypoints are being generated.

No, it seems to work fine each time the key poins are generated.

• Please also clarify what the reported "70% CPU usage" refers to. For example, on macOS, CPU usage is not normalized to 100%. On a 4-core system, a single process can report up to 400% CPU usage, corresponding to full utilization of all cores.

On Windows, I checked Task Manager, and under Apps where Firefox is running, I noticed the CPU spiking to around 70%. - see image.

Let me know if I can help with other info.

Comment 5

[Aristide Tossou]

Thanks. This is really helpful.

Comment 6

[Greg Tatum [:gregtatum]]

This issue is pretty vague in terms of action items. I think we know that this feature can be quite intensive, and we're doing active work to understand and quantify it. I'm going to WONTFIX since we'll probably file more specific things here and decide on how we'll run this feature.