1005005 - pdf.js causes memory use to spike by 2Gb

Status: RESOLVED WORKSFORME

(Firefox :: PDF Viewer, defect, P3)

Description

[David Teller [:Yoric] - still alive but not very active]

(reported using the contribute form)

STR:
1. Open http://tarifs.lessentiel.lu/docs/TARIFS2014_IMPRESSION.pdf
2. Watch about:memory 

Result: Memory increases by 2+Gb.

Comment 1

[Nicholas Nethercote [inactive]]

With a version of pdf.js from early January, I was able to get RSS up to about 2,200 MiB.

With a development version, I haven't managed to get RSS to get higher than 700 MiB, and speed is much better.

It's still pretty slow, though. The newspaper thumbnails on pages 7 and 8 in particular are a real stress test. The time is mostly due to the text layer -- page 8 has almost 12,000 text divs! -- so bug 1054161 will help.

Comment 2

[Nicholas Nethercote [inactive]]

Here's the operator histogram for pages 7 and 8:

> (  1)    29072 (17.7%, 17.7%): showText
> (  2)    27439 (16.7%, 34.5%): moveText
> (  3)    22853 (13.9%, 48.4%): setWordSpacing
> (  4)    22812 (13.9%, 62.3%): setCharSpacing
> (  5)     9927 ( 6.1%, 68.4%): restore
> (  6)     9927 ( 6.1%, 74.4%): save
> (  7)     7332 ( 4.5%, 78.9%): transform
> (  8)     6605 ( 4.0%, 82.9%): constructPath

There are *many* sequences like this:

> setCharSpacing: [0.004]
> setWordSpacing: [-0.004]
> moveText:       [1.222,0]
> showText:       [[{"fontChar":"u","unicode":"u","accent":null,"width":630},{"fontChar":"l","unicode":"l","accent":null,"width":315}]]
> setCharSpacing: [0]
> setWordSpacing: [0]
> moveText:       [0.947,0]
> showText:       [[{"fontChar":",","unicode":",","accent":null,"width":278}]]
> setCharSpacing: [0.003]
> setWordSpacing: [-0.003]
> moveText:       [0.686,0]
> showText:       [[{"fontChar":"1","unicode":"1","accent":null,"width":556},{"fontChar":"6","unicode":"6","accent":null,"width":556}]]
> moveText:       [1.55,0]
> showText:       [[{"fontChar":"a","unicode":"a","accent":null,"width":556},{"fontChar":"n","unicode":"n","accent":null,"width":648}]]

Two glyphs per |showText| is typical (and also explains why there are so many text layer divs).

AFAICT, a lot of these |setWordSpacing| ops are useless because they only have an effect if there is a null glyph (representing a word space) present in a |showText| before the next |setWordSpacing|. But |setWordSpacing| is not an expensive op, so it might not be worth trying to remove them.

Comment 3

[Nicholas Nethercote [inactive]]

I'm tempted to close this bug report. Memory usage, while still high, is 3x better than it was when the bug was reported. Thoughts?

Comment 4

[mirh]

https://www.dolby.com/us/en/guide/dolby-atmos-speaker-setup/5.1.2-overhead-speaker-setup-guide.pdf
https://fosdem.org/2018/schedule/event/om_av1/attachments/slides/2639/export/events/attachments/om_av1/slides/2639/av1update.pdf

Both these pdfs makes memory usage explode by at least 1GB and half.

Comment 5

[mirh]

https://web.archive.org/web/20141025064635fw_/http://tarifs.lessentiel.lu/docs/TARIFS2014_IMPRESSION.pdf

OP's case is still not optimal probably, but it takes only a bit more than 400MB now (or more than 3 times SumatraPDF).

My two examples are still in outrage-territory though.

Comment 6

[Wayne Mery (:wsmwk)]

Only https://fosdem.org/2018/schedule/event/om_av1/attachments/slides/2639/export/events/attachments/om_av1/slides/2639/av1update.pdf still exists. I cannot reproduce the issue on Mac using 90.0b8.

Can you still reproduce?

Comment 7

[mirh]

I think this is maybe an equivalent of my first link.

And even if I'm not really in the best position to measure ram now, there still seems to be some important spikes.
It's not bad but they don't really look proportionate either.

Comment 8

[ISHIKAWA, Chiaki]

Attachment: Memory usage increase during rendering of URL in comment 7.

(In reply to mirh from comment #7)

I think this is maybe an equivalent of my first link.

And even if I'm not really in the best position to measure ram now, there still seems to be some important spikes.
It's not bad but they don't really look proportionate either.

Hi,
I have been trying to figure out if a particular PDF from a Japanese government is s causing a problem similar to yours, but I think
my test with FF 90.0.2 (64 bit) on a windows 10 Pro PC with 32GB of memory did not really reproduce your issue even with the link in comment 7.
I am attaching a memory usage increase captured by task manger during the rendering of the link in comment 7.
You can see it is a very small bump and hardly big. (I am already running a lot of processes. And approximately 8GB of memory was used.)
It is about 400-600MB (the grid separation of the graph is about 3.2 GB, and the bump is less than approximately, I say 600- MB. Of course, if I have 8GB memory and already is in swapping situation this 400-600MB may be a problem. But compared with other large page rendering this link did not feel heavy.

Comment 9

[mirh]

I don't really think a scale-less graph from a 32GB system is really the best way to measure ram usage.
Checking the delta in commit size is usually way more reliable.

Anyhow, something around 400-600MB was also the ballpark of my figure.
Now, I don't know if that couldn't actually be warranted for your document, but at least with mines it still seemed somewhat disproportionate.

Comment 10

[Calixte Denizet (:calixte)]

I checked the memory used for the different pdfs in this bug report and I can't see anything wrong on mac (M1, Ventura 13.1).
Since this bug report is a bit old and a lot of improvements have been made over the years, I'm closing this bug, but if anyone has an obvious proof that something is wrong, please reopen it.