The default bug view has changed. See this FAQ.

Excessive memory while loading PDF thumbnail view

RESOLVED DUPLICATE of bug 878397

Status

()

Firefox
PDF Viewer
P3
normal
RESOLVED DUPLICATE of bug 878397
4 years ago
3 years ago

People

(Reporter: ashughes, Unassigned)

Tracking

(Blocks: 1 bug, {verifyme})

Trunk
x86_64
Windows 8
verifyme
Points:
---
Dependency tree / graph
Bug Flags:
in-qa-testsuite ?

Firefox Tracking Flags

(firefox19-, firefox20-, firefox29 fixed)

Details

(Whiteboard: [pdfjs-c-performance], URL)

> Originally report in bug 820379 comment 7

When I open a PDF (see URL) and turn on the thumbnail pane, I noticed the memory usage climbs to ~3.3 GB. I'm not sure if this is the only use case where PDF.js is using excessive memory. It might be prudent to do some exploratory analysis to find out. In some cases (ex. bug 820379) this results in stability and performance issues.
The million dollar question of course is whether this should block enabling of PDF.js in Firefox 19? or whether we should ship with this known issue and hotfix disable it if feedback indicates it's a prevalent issue.
The page appears to be a series of scanned high resolution images.

While loading, about:memory for the relevant tab looks like this:
│  ├──1,515.25 MB (67.32%) -- top( ... )/active/window( ... )
│  │  ├──1,511.84 MB (67.17%) -- js/compartment( ... )
│  │  │  ├──1,501.60 MB (66.72%) -- objects-extra
│  │  │  │  ├──1,501.44 MB (66.71%) ── elements
│  │  │  │  └──────0.16 MB (00.01%) ── slots
│  │  │  └─────10.24 MB (00.45%) ++ (8 tiny)

As you can see it is almost entirely JS elements.

After hitting minimize memory usage the memory goes down to a more reasonable quantity:

│  ├───77.84 MB (11.23%) -- top( ... )/active/window( ... )
│  │   ├──74.44 MB (10.74%) -- js/compartment( ... )
│  │   │  ├──66.20 MB (09.55%) -- objects-extra
│  │   │  │  ├──66.04 MB (09.53%) ── elements
│  │   │  │  └───0.16 MB (00.02%) ── slots
│  │   │  └───8.24 MB (01.19%) ++ (6 tiny)
│  │   └───3.41 MB (00.49%) ++ (4 tiny)

I don't know if this is a matter of pdf.js allocating too many things, the GC not running enough, or some combination of both.
Oh, and this was without the thumbnail view.

When I scrolled through the document again, the memory when up to about 1.5 gigs again.  After waiting a few seconds, it dropped back down to 77mb.  So it is more than just the initial loading that is causing heavy memory usage, I guess, and the GC does seem to take care of the memory within, say, a minute.
tracking-firefox19: --- → ?

Comment 4

4 years ago
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #0)
> When I open a PDF (see URL) and turn on the thumbnail pane, I noticed the
> memory usage climbs to ~3.3 GB. I'm not sure if this is the only use case
> where PDF.js is using excessive memory. It might be prudent to do some
> exploratory analysis to find out. In some cases (ex. bug 820379) this
> results in stability and performance issues.

We should track PDF.js OOM crashes (and we are), but not temporary/excessive memory usage.
tracking-firefox19: ? → -
tracking-firefox20: --- → -
FWIW, this would cause an OOM situation on PCs with less than 4GB (fairly common AFAIK).
Depends on: 839631
Blocks: 740171

Updated

4 years ago
Priority: -- → P3
Whiteboard: [Memshrink] → [Memshrink][pdfjs-c-performance]
Taking the MemShrink tag off because we have a tag on 839631.
Whiteboard: [Memshrink][pdfjs-c-performance] → [pdfjs-c-performance]
Dave, could this be covered by a Mozmill Endurance test?
Flags: in-qa-testsuite?(dave.hunt)
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #7)
> Dave, could this be covered by a Mozmill Endurance test?

Yes, we could definitely add a few PDF.js related endurance tests (opening/closing a PDF, entering/leaving thumbnail view, etc).
Blocks: 851507
Thanks Dave, I've filed bug 851507 to track development of an Endurance test once *this* bug is resolved.
Blocks: 881974

Updated

4 years ago
Flags: in-qa-testsuite?(dave.hunt) → in-qa-testsuite?
After investigation, I've found that this has the same root cause as bug 878397 -- we're creating lots of these enormous mask arrays. Just like in that bug, we see "explicit" measurements that are much higher than the "resident" measurements.

2,639.78 MB (100.0%) -- explicit
├──2,482.55 MB (94.04%) -- window-objects
│  ├──2,459.42 MB (93.17%) -- top(file:///home/njn/37355_1_A.pdf, id=8)
│  │  ├──2,458.45 MB (93.13%) -- active/window(file:///home/njn/37355_1_A.pdf)
│  │  │  ├──2,457.40 MB (93.09%) -- js-compartment(resource://pdf.js/web/viewer.html, file:///home/njn/37355_1_A.pdf)
│  │  │  │  ├──2,456.43 MB (93.05%) -- objects
│  │  │  │  │  ├──2,456.01 MB (93.04%) -- malloc-heap
│  │  │  │  │  │  ├──2,455.96 MB (93.04%) ── elements/non-asm.js
│  │  │  │  │  │  └──────0.05 MB (00.00%) ── slots
...
  733.56 MB ── resident
  721.81 MB ── resident-unique
3,393.72 MB ── vsize
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 878397
Marking this fixed by bug 878397 and flagging for verification.

Dave, now that this is fixed can we get traction on bug 851507?
status-firefox29: --- → fixed
Flags: in-qa-testsuite? → in-qa-testsuite?(dave.hunt)
Keywords: verifyme
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #11)
> Marking this fixed by bug 878397 and flagging for verification.
> 
> Dave, now that this is fixed can we get traction on bug 851507?

Bug 851507 is still blocked by bug 830379.
Flags: in-qa-testsuite?(dave.hunt) → in-qa-testsuite?
You need to log in before you can comment on or make changes to this bug.