Memory usage while reading big PDFs gradually increases until browser OOMs




6 years ago
4 years ago


(Reporter: gcp, Unassigned)


(Blocks: 1 bug)

21 Branch
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [pdfjs-c-performance])


(3 attachments)



6 years ago

1) Load a big book, e.g.
2) Start scrolling, giving some minimal time to let individual pages load.
3) Watch memory usage.
4) See browser go boom as Firefox exceeds 2Gb RAM usage.

Looks like decoded/rendered pages are cached but never freed.


6 years ago
Whiteboard: [MemShrink]

Comment 1

6 years ago
Maybe Firefox should discard PDF pages which are not displayed, like it does for images (if that's not the case).
Priority: -- → P4
Whiteboard: [MemShrink] → [MemShrink][pdfjs-c-performance]
An about:memory measurement would be very helpful.  If you're on Nightly, please "Measure and save" and attach the resulting .json.gz file.  Thanks!
Whiteboard: [MemShrink][pdfjs-c-performance] → [pdfjs-c-performance]


6 years ago
See Also: → bug 849038

Comment 3

6 years ago
Created attachment 764144 [details]
about:memory report
This is WFM using Firefox 2 and newer. Getting ~700/750 MB Ram Usage on Scrolling through the first 20 Pages.

Comment 5

5 years ago
Still trivially reproduces on currently Nightly.

>Getting ~700/750 MB Ram Usage on Scrolling through the first 20 Pages.

Uh, the document has 3800+ pages. Try reading more than 1% of it.
Depends on: 965130
gcp, how does Nightly do now? Memory usage seems ok to me now, considering the document size -- I couldn't get Firefox's RSS above ~800 MiB -- but maybe I'm not interacting with the document in the same way you are.

Comment 7

4 years ago
Created attachment 8470667 [details]

Comment 8

4 years ago
I can still get it arbitrarily high by browsing through the document. It seems to raise less sharply (i.e. pdf.js memory usage is better), but still keeps going up (i.e. it's still *leaking*).

I attached a memory report where it's using about 2.3G.
This is interesting:

> │    ├──719.08 MB (41.94%) -- top(, id=121)
> │    │  ├──653.60 MB (38.12%) -- active/window(
> │    │  │  ├──402.67 MB (23.48%) -- dom
> │    │  │  │  ├──390.55 MB (22.78%) ── orphan-nodes
> │    │  │  │  └───12.12 MB (00.71%) ++ (5 tiny)

As is this:

> 4,372.27 MB ── gpu-committed
> 1,580.04 MB ── gpu-dedicated
>    20.52 MB ── gpu-shared
gcp: another interesting experiment would be to append "#textLayer=off" to the URL through which you access the file. This disables the text layer, which means you won't be able to select text, but it might make pdf.js faster and use less memory. I think it will also prevent orphan nodes from accumulating, since the text layer is the only part of pdf.js (AFAIK) that involves lots of DOM nodes.

Comment 11

4 years ago
Created attachment 8472136 [details]
memory-report.json.gz with #textLayer=off

Comment 12

4 years ago
Sounds like you found it indeed. Memory usage increases by about 300M when the PDF is opened, but increases negligibly after that and barely went over 900M even after reading halfway through it.
Bug 1054161 may help substantially.
You need to log in before you can comment on or make changes to this bug.