Closed
Bug 1037977
Opened 10 years ago
Closed 10 years ago
High heap-unclassified after opening a lot of pdfs
Categories
(Toolkit :: about:memory, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: guijoselito, Unassigned)
Details
Attachments
(1 file)
1.61 MB,
text/plain
|
Details |
I was going through some pdf viewer bugs here on bugzilla.
After testing some of them, and filling one bug, I checked about:memory and Windows' Task Manager.
Task Manager shows 520MB for Firefox (Nightly).
But about:memory shows something totally different.
I used the feature "Measure and save" and am attaching it here.
There is 720MB of explicit, with 51% of it being heap-unclassified.
Comment 1•10 years ago
|
||
These are some strange numbers:
> 720.01 MB -- explicit
> 367.62 MB ── heap-unclassified
> 590.66 MB ── heap-allocated
> 1,000.31 MB ── private
> 549.79 MB ── resident
It suggests(?) that there are large allocations -- mostly outside the heap, but also partly on the heap -- happening, but lots of the memory isn't being touched.
Are you in a position to do a build with DMD enabled? That will give us more info about the heap-unclassified. Instructions are at https://wiki.mozilla.org/Performance/MemShrink/DMD#Desktop_Firefox_.28Windows.29.
Reporter | ||
Comment 2•10 years ago
|
||
Unfortunately, I'm just an end user. But I'll try to find minimal steps to reproduce.
Just one note: that memory from heap-unclassified never went away. Just when I closed Firefox.
Reporter | ||
Comment 3•10 years ago
|
||
I couldn't reproduce the problem again, unfortunately.
The only thing I found is an easy way to produce a lot of heap-unclassified, but it is a stress test.
Open all of this PDFs[1] at the same time, and then close them. Maybe scrolling them is also important, mainly the last one, which is huge and loads a lot of fonts.
During the test, Firefox peaked at 2 GB. When I closed all of them, went to about:memory, clicked minimize memory usage and then "Measure". I got 30% of heap-unclassified (120 out of 400MB), which never went away.
[1]
https://bug844092.bugzilla.mozilla.org/attachment.cgi?id=717103
http://lib.tkk.fi/Dipl/2002/urn007413.pdf
http://www.tit-szfvar.sulinet.hu/versenyek/2012/matematika/MatekMegold6.pdf
http://www.kk-mic.jp/somu/kigyo/documents/h2205.pdf
http://miracle.rpz.name/shared/anketa.pdf
http://www.wakmet.com.pl/sites/default/files/katalog/00100_218%20%20ANG.pdf
https://bug762244.bugzilla.mozilla.org/attachment.cgi?id=630713
http://www.ic.unicamp.br/~pannain/mc404/aulas/pdfs/Art%20Of%20Intel%20x86%20Assembly.pdf
https://bug841806.bugzilla.mozilla.org/attachment.cgi?id=714461
https://bug846014.bugzilla.mozilla.org/attachment.cgi?id=826440
https://bug946506.bugzilla.mozilla.org/attachment.cgi?id=8342707
https://bug750664.bugzilla.mozilla.org/attachment.cgi?id=619898
http://www.oranjewoudnv.nl/sites/default/files/Oranjewoud%20NV%20-%20%20besluiten%20aandeelhoudersvergadering%2011%20juni%202014.pdf
http://studioforcreativeinquiry.org/public/warhol_amiga_report_v10.pdf
https://issues.apache.org/jira/secure/attachment/12521771/AnnahmeReport_MitRussischTest.pdf
http://www.w3.org/WAI/WCAG20/Techniques/working-examples/PDF17/page-numbers.pdf
https://issues.apache.org/jira/secure/attachment/12546323/missing_image.pdf
http://www.dynacw.co.jp/Portals/3/fontsamplepdf/sample_4942546800828.pdf
Comment 4•10 years ago
|
||
> I couldn't reproduce the problem again, unfortunately.
Given that, I will close this bug.
The good news is that I profiled pdf.js with most of the documents in comment 3. And there have been numerous recent improvements to pdf.js that reduce its memory usage.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•