Open Bug 1705931 Opened 4 years ago Updated 20 days ago

Reduce memory usage by unloading ReaderWorker.js and cld-worker.js chrome workers after a period of inactivity

Categories

(Toolkit :: Reader Mode, defect, P3)

Firefox 87
x86_64
Linux
defect

Tracking

()

People

(Reporter: jeffreybosboom, Unassigned)

References

Details

Entering Reader Mode causes ReaderWorker.js and cld-worker.js chrome workers to be started. They seem to persist for the life of the process. about:memory attributes 4 MB to ReaderWorker.js and about 17 MB to cld-worker.js, but I know from bug 1003120 that most of cld-worker.js's reported memory isn't committed.

To measure the memory occupied by these workers, I did the following in Nightly 20210415214643:

  1. Create a fresh profile and start Nightly.
  2. Enter Preferences and set the number of content processes to 1 (to easily keep the content process alive after closing the reader mode tab).
  3. Open mozilla.org in a tab and wait for it to finish loading.
  4. Open about:memory, minimize memory usage, then save a memory report.
  5. Open en.wikipedia.org in another tab. Reader mode is available on the Wikipedia front page.
  6. Enter reader mode by clicking on the reader mode button in the URL bar and wait for it to finish rendering.
  7. Exit reader mode by clicking the reader mode button again, then close the Wikipedia tab.
  8. In the about:memory tab, minimize memory usage, then save a memory report.
  9. Use about:memory to load and diff the memory reports.
  10. Wait a while, minimize memory usage, then take a memory report. Observe that both workers are still loaded.

Repeating the above steps a few times, the diff shows about a 10 MB increase in the content process's "resident" memory (on one trial, the difference was 16 MB). The diff shows most of the increase is due to the two workers, though about 700 KB is attributed to reader-mode-related chrome vector images.

In my current session on my main profile on the release channel (Firefox 87.0), all 8 of my (shared, non-Fission) content processes have these two workers loaded, even though I haven't used reader mode for a couple of days. I understand there is a cost to creating these workers so they shouldn't be unloaded immediately, but I don't think retaining them for the life of the process is the correct policy. LanguageDetector.jsm, which ReaderMode._assignLanguage calls into, already has code to terminate the worker after an idle timeout, but the timer is only set if the detector processed a long string.

(Bugzilla meta: I'm pretty sure this belongs in the Reader Mode component, but that isn't one of the options on the bug entry form. I've also set the platform as Linux because I haven't tried to reproduce on other operating systems.)

Hi Jeffrey, thanks for logging this issue, I was able to reproduce this issue in our latest Nightly build on Windows 10 using your exact steps and after a while in the last memory report I would still see :

│ ├──17.31 MB (30.96%) -- worker(resource:///modules/translation/cld-worker.js, 0x173d2097000)
│ └───2.62 MB (04.69%) -- worker(resource://gre/modules/reader/ReaderWorker.js, 0x173d2094800)

These two are still in the Explicit Allocations section, Im not sure how to read these memory reports, I will set the component for it to Toolkit Reader mode, but in case this issue belongs in the Memory Allocation component or if there is a more suitable one please feel free to change it.
Im setting a component in the hopes that one of our devs can take a look and he would know more about this issue.

Status: UNCONFIRMED → NEW
Component: Untriaged → Reader Mode
Ever confirmed: true
Product: Firefox → Toolkit
Severity: -- → S3
Priority: -- → P3

TBH it's not clear to me that the use of a worker for reader mode itself has any point at this point, so if we were to do anything here, I'd sooner just get rid of that worker completely.

Whiteboard: [fxperf]
Whiteboard: [fxperf] → [fxperf:p3]
Whiteboard: [fxperf:p3]

I just went to about:debugging#/runtime/this-firefox and found I have 58 resource://gre/modules/translations/cld-worker.js workers reported, so the resource usage concerns here are potentially more significant than just using 1 when there should be 0.

Blocks: 1985740
No longer blocks: 1985740
Depends on: 1985740

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #3)

I just went to about:debugging#/runtime/this-firefox and found I have 58 resource://gre/modules/translations/cld-worker.js workers reported, so the resource usage concerns here are potentially more significant than just using 1 when there should be 0.

I filed bug 1985740 for the translations use that is likely causing this (esp. if seen without a corresponding number of reader mode workers - but anyway it seems unlikely you used reader mode on 58 distinct domains/processes that then stayed alive).

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #3)

I just went to about:debugging#/runtime/this-firefox and found I have 58 resource://gre/modules/translations/cld-worker.js workers reported, so the resource usage concerns here are potentially more significant than just using 1 when there should be 0.

This should be fixed now that Bug 1967758 has landed.

You need to log in before you can comment on or make changes to this bug.