Created attachment 8455019 [details] Guilherme-memory-report.json 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.
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.
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.
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 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.  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
> 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
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.