Closed Bug 868949 Opened 11 years ago Closed 10 years ago

Big memory usage opening a pdf document on Windows, especially "gfx-d2d-vram-drawtarget"

Categories

(Firefox :: PDF Viewer, defect, P4)

Product:
Firefox
Component:
PDF Viewer
Version:
20 Branch
Platform:
x86_64
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 34

People

(Reporter: sbi82, Unassigned)

References

Details

(Whiteboard: [pdfjs-c-performance] [bugday-20140820]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949

Steps to reproduce:

I try to open this document:

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf

With firefox 20.0.1 and pdf.js version 0.8.1


Actual results:

Scrolling the document up and down, Firefox uses a lot of memory. Expecially, looking about:memory, it seems that a lot of memory is used by gfx-d2d-vram-drawtarget. At the moment is 751.02MB but it increase continuosly scrolling the document and never go down. The only way to make this value lower, is to close the document and press "Minimize memory usage" button. In this way, that value goes down to 17MB (in this case, the value can change but it always go significantly down when I press the button).
The video card used (I say this because I read gfx-d2d-vram-drawtarget) is an integrated Intel HD Graphics and the driver version is: 8.15.10.2827.
The operative system is Windows Seven 64 bit


Expected results:

I think that firefox should use a lot less memory since the document is not so big.
Component: Untriaged → PDF Viewer
Whiteboard: [MemShrink]
We're having trouble replicating.  Are you able to replicate on another machine?
Priority: -- → P4
Whiteboard: [MemShrink] → [MemShrink][pdfjs-c-performance]
Sure tried with a pc with Windows XP SP3 and a Nvidia 8800GT

Scrolling up and down the document I see these strange numbers in about:memory:

794,821,956 B ── canvas-2d-pixel-bytes
795,686,168 B ── gfx-surface-win32

If I close that page and I minimaze memory usage with the button in about:memory I see:

1,900,800 B ── canvas-2d-pixel-bytes
2,670,212 B ── gfx-surface-win32

The above values change a little bit if I press various times the "minimize memory usage" button..
If you need any other information, let me know..
I can also confirm this behavior on latest nightly (23.0a1 (2013-05-07)) and same hardware of Comment 2...
Definitely seeing this. I'm seeing this both with and without hardware acceleration enabled.

Without hardware acceleration the majority of the memory seemed to be heap-unclassified.

1,239.34 MB (100.0%) -- explicit
├────986.04 MB (79.56%) ── heap-unclassified

With hardware acceleration, like comment 0, the bulk of the memory was being used in gfx-d2d-vram-drawtarget

1,254.41 MB ── gfx-d2d-vram-drawtarget

I also crashed the browser after scrolling for a while.

https://crash-stats.mozilla.com/report/index/bp-51992ed3-902c-4a70-9bce-8fb022130508

Could any of these be related?

https://bugzilla.mozilla.org/show_bug.cgi?id=863159
https://bugzilla.mozilla.org/show_bug.cgi?id=842962
Whiteboard: [MemShrink][pdfjs-c-performance] → [MemShrink:P2][pdfjs-c-performance]
+cc: the GFx/Image experts. Is this related to bug 869252?
What kind of memory usage should we expect?  The pages are 842x595 (I think).  If we can allocate exactly that size, we end up with ~350M.  If we need to allocate power of two texture sizes, we end up with 720M.  I'm not arguing there is no problem, just trying to figure out what the expectations are.
On OSX, I see 1.3G canvas-2d-pixel-bytes, so I'm not sure this is Windows specific.
OS: Windows 7 → All
In order to provide additional information, I've just updated firefox to 21 branch on the same hardware of comment 1 and I see the same problem.

For milan: I sincerely don't know how many memory consumptation to expect but, if I open the same document with Chrome 26.0.1410.64, I don't see such a big memory usage. I've opened the task manager inside of chrome and I see that, for the tab where I open the pdf document, the memory usage remain always below 60MB.
(In reply to Milan Sreckovic [:milan] from comment #6)
> What kind of memory usage should we expect?

You tell us!

If the claim is that PDF.js can compete with native PDF readers, and if we use an order of magnitude more memory on this PDF than a regular reader does (which may may not be the case; I haven't tested), then certainly that's a problem somewhere...  It may not be a gfx bug.
Indeed - my question above wasn't meant to defend the current state; I'm trying to establish the target so that we know when we're done.  For example, we can't hit the 60MB target by rendering and keeping all the pages as images.  The goal could drive the implementation.  If we have to get to 500MB, then there is probably something that can be done beyond not caching everything.
As far as comparison to Chrome - I believe they're using the Adobe plug-in to render the PDFs - I know that is faster than the JS approach we have, but I'm wondering if some of the memory used is not reported in Chrome because it's done with the plug-in.  Again, just for the purposes of a good target to aim for.
Whiteboard: [MemShrink:P2][pdfjs-c-performance] → [pdfjs-c-performance]
I am also seeing extremely high memory usage of 1GB or more when viewing PDF files of scanned images.  See further details at https://github.com/mozilla/pdf.js/issues/3630.  Please let me know if I can provide more information to help resolve this issue.
Nicholas, was this fixed by one of your awesome patches?
Flags: needinfo?(n.nethercote)
(In reply to Guilherme Lima from comment #12)
> Nicholas, was this fixed by one of your awesome patches?

It's possible, but I don't know. The problem was with Windows-specific graphics memory, and I don't have a Windows machine to test on.

Stefano, are you able to re-test with a Nightly build (nightly.mozilla.org)?
Flags: needinfo?(n.nethercote) → needinfo?(sbi82)
(In reply to Nicholas Nethercote [:njn] from comment #13)
> Stefano, are you able to re-test with a Nightly build (nightly.mozilla.org)?

Yes I've tested with the latest nightly the pdf I mentioned above. The hardware is the same of comment 2 with Windows XP SP3.

I think that the memory consumption is the same but the scrolling is faster then the last time I tried.
However the heap unclassified memory value is almost the same.
Maybe tomorrow I will try with a pc with Windows Seven and give you some new number.

P.S.
My pdf.js version is 0.8.649; I tried to see if there is a newest one but it can't find new update even if my version seems to be a 14 november 2013 version.
Am I using an old pdf.js version?
Flags: needinfo?(sbi82)
> My pdf.js version is 0.8.649; I tried to see if there is a newest one but it
> can't find new update even if my version seems to be a 14 november 2013
> version.
> Am I using an old pdf.js version?

Bug 965861 indicates that 0.8.990 is the most recent import, and you'll need that to get all the recent memory optimizations. It was imported to mozilla-central on Jan 31, so it should have been in the Nightly build from Feb 2 or perhaps Feb 3.

How did you determine the pdf.js version?
We went from bundling 0.8.641 to version 0.8.681 with Firefox, so I'm guessing the extension?

Stefano, if you want to try a Firefox nightly build, it should have the fix. Otherwise, you can try the extension from the link below. As of this second, it's version 0.8.997.
http://mozilla.github.io/pdf.js/extensions/firefox/pdf.js.xpi
Thank you, Ryan; I thought that pdf.js update itself automatically.. Now I've the 0.8.997 version and I'll give a try.

Nicholad, I've seen that in the addon menu.. :-)
As a fast look, the problem is greatly reduced. I've not time for a deep test (maybe tomorrow) however, looking to task manager, I opened the pdf when the firefox.exe process was using about 600MB. After having completely scrolled down the document, firefox.exe used about 1.1GB of ram.

And what is great is that, when you stop scrolling, it seems that firefox releases memory more faster now and without the needs to close the document.

So, the memory usage maybe it's still high.. But greater reduced! I think that this update is a big improvement.
Thanks, Stefano. I'm glad it's reduced. I just tried this document again, and on my Linux desktop I don't see an improvement -- with both the older and newer versions of pdf.js, Firefox's RSS peaks at about 450 MiB while scrolling through the document. And I don't think the document uses scanned images or image masks, which is where most of the optimization has happened. Perhaps some other optimizations I'm unaware of have been done recently. But clearly the memory consumption on Windows is much higher than on Linux, so I think it's worth keeping this bug open.
Summary: Big memory usage opening a pdf document → Big memory usage opening a pdf document on Windows, especially "gfx-d2d-vram-drawtarget"
Firefox 33, currently on the Aurora branch (aurora.mozilla.org), has some nice pdf.js improvements (https://blog.mozilla.org/nnethercote/2014/06/16/an-even-slimmer-pdf-js/). I wonder how it performs with this document.
Using Nightly, canvas-2d-pixel-bytes never went above 70 MB and gfx-surface-win32 never went above 230 MB. (Win7 - Intel HD3000)
(In reply to Guilherme Lima from comment #21)
> Using Nightly, canvas-2d-pixel-bytes never went above 70 MB and
> gfx-surface-win32 never went above 230 MB. (Win7 - Intel HD3000)

Thanks for the data! Were you able to reproduce the high memory usage with older versions? I'd like a report of a clear "before and after" improvement, from you or Stefano (or anybody else) before closing this.
Using Firefox Beta, I see 433.52 MB for canvas-2d-pixels and 1,310.20 MB for gfx-d2d-vram-draw-target. So, clearly, a huge improvement. Awesome work!
Thanks for the measurements, Guilherme. I think this bug can be closed. There are other bugs and PRs still open for other aspects of pdf.js's memory usage, e.g. https://github.com/mozilla/pdf.js/issues/1887.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
¡Hola Stefano!

Could you please do a test and if things have in fact improved change the Status below from RESOLVED to VERIFIED?

¡Gracias!
Alex
Flags: needinfo?(sbi82)
Whiteboard: [pdfjs-c-performance] → [pdfjs-c-performance] [bugday-20140820]
Sorry for the long delay here. I've tried to make some measurements with the pdf document on my first post (and the latest nightly obviously).
Unfortunately I don't have anymore the machine with windows xp. But I've instead a machine with windows Seven and an ati radeon 7700 series.
Looking task manager, I opened the pdf when firefox.exe was using about 490MB of ram (some tabs opened and after an hour of surfing); I scrolled the document to the last page and the occupied ram have became: 550MB. A very nice reduction in memory usage! 

These the lines in about:memory I was speaking about in my first comment

66.31 MB ── canvas-2d-pixels
    0.00 MB ── gfx-d2d-surface-cache
    4.00 MB ── gfx-d2d-surface-vram
  215.37 MB ── gfx-d2d-vram-draw-target
    6.17 MB ── gfx-d2d-vram-source-surface
    0.10 MB ── gfx-surface-win32
    0.00 MB ── gfx-textures
    0.00 MB ── gfx-tiles-waste

gfx-d2d-vram-draw-target is not so little but it is very reduced!

I think this bug is very very reduced (and maybe resolved)!

Nice work!
Flags: needinfo?(sbi82)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.