After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747934 - Slowing down after document reloads
Slowing down after document reloads
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: PDF
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-15 15:42 UTC by Johann Glaser
Modified: 2018-05-22 16:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Johann Glaser 2015-04-15 15:42:05 UTC
Evince is very fast to display a PDF file when scrolling through the document. However, when this document is reloaded a few times, switching to different pages gets slower and slower.

Use case: Writing a larger document with LaTeX (pdflatex). Every time I recompile the document, Evince reloads the new PDF file (which is great). Unfortunately, switching pages (PgUp/PgDn keys, clicking on hyperref links), or more precisely, displaying the new pages, gets slower and slower (with high CPU load), so I have to quit and restart Evince every hour. After restart, Evince is back to high speed.
Comment 1 José Aliste 2015-04-15 16:26:12 UTC
Can you check the memory used by evince? and the cpu used? like monitoring it. I haven't had any problem similar to what you describe and my usecase is exactly the same.
Comment 2 Germán Poo-Caamaño 2015-04-15 19:45:01 UTC
Does this behaviour occur with one particular document or with any document you are working on?

If the former, could you share the document to try to reproduce the issue?

In addition, please be more precise to define "larger document", how many pages, figures, how big the figures, ...
Comment 3 Johann Glaser 2015-04-16 20:26:31 UTC
Thanks for asking questions to narrow down the problem! The document I'm currently working on has a total of 145 pages (but a lot of that are notes written with the alltt environment, and it has many BibTeX references). The file size (2.1MB) did not change by more than a few kB. I was mostly working on some corrections, some overview plans, ... The file only has a low number of figures, many of them are drawn with TikZ, and there are a few PNGs and JPGs which contribute most to the file size. I'm sorry that I can't share that document because its my thesis which can't be published before the official submission and examination. But I remember similar slow-downs with previous documents too.

Regarding the CPU usage: I have "gkrellm" running permanently and I see 100% CPU while going through the document. "top" shows that the "evince" process is the one with the high CPU usage.

Regarding memory usage: I've started the process yesterday at 17:44. It showed a continuously growing slow-down up to now. The memory usage also grew, but sometimes RSS even went back, especially if I didn't change the document for a while (sounds like garbage collection).

Here is a collection of "ps axuw" output taken at irregular points in time. I suspended the PC during the night (suspend to RAM). The last line shows a new process after I stopped the old slow process, which required approx. 1 second per page). Note: The "TIME" column shows the total CPU usage of the process in the format mm:ss, i.e., at the end Evince has consumed a total of 2 minutes and 34 seconds for "stuff".

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
hansi    12352  1.6  1.1 826824 96776 pts/2    Sl   17:44   0:00 /usr/bin/evince thesis.pdf
hansi    12352  1.3  1.1 826824 96776 pts/2    Sl   17:44   0:00 /usr/bin/evince thesis.pdf
hansi    12352  1.2  1.1 826824 96776 pts/2    Sl   17:44   0:00 /usr/bin/evince thesis.pdf
hansi    12352  1.2  1.1 826824 96776 pts/2    Sl   17:44   0:00 /usr/bin/evince thesis.pdf
hansi    12352  1.2  1.1 826824 96776 pts/2    Sl   17:44   0:00 /usr/bin/evince thesis.pdf
hansi    12352  1.5  1.3 809344 110708 pts/2   Sl   17:44   0:01 /usr/bin/evince thesis.pdf
hansi    12352  1.7  1.3 809516 111256 pts/2   Sl   17:44   0:01 /usr/bin/evince thesis.pdf
hansi    12352  0.7  1.4 875052 115548 pts/2   Sl   17:44   0:03 /usr/bin/evince thesis.pdf
hansi    12352  0.1  1.3 940760 107960 pts/2   Sl   17:44   0:06 /usr/bin/evince thesis.pdf
hansi    12352  0.1  1.3 940760 107960 pts/2   Sl   17:44   0:06 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.6 1210584 133600 pts/2  Sl   17:44   0:13 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.6 1210584 133600 pts/2  Sl   17:44   0:13 /usr/bin/evince thesis.pdf
hansi    12352  0.1  1.6 1210584 138148 pts/2  Sl   17:44   0:30 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.6 1210584 137224 pts/2  Sl   Apr15   0:31 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.7 1210584 142172 pts/2  Sl   Apr15   0:32 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.7 1210584 142952 pts/2  Sl   Apr15   0:35 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.7 1210584 143744 pts/2  Sl   Apr15   0:36 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.8 1212972 150752 pts/2  Sl   Apr15   0:42 /usr/bin/evince thesis.pdf
hansi    12352  0.0  1.9 1212976 161084 pts/2  Sl   Apr15   0:43 /usr/bin/evince thesis.pdf
hansi    12352  0.0  2.0 1213492 165444 pts/2  Sl   Apr15   0:50 /usr/bin/evince thesis.pdf
hansi    12352  0.0  2.0 1213492 167224 pts/2  Sl   Apr15   0:52 /usr/bin/evince thesis.pdf
hansi    12352  0.0  2.0 1213492 168348 pts/2  Sl   Apr15   1:05 /usr/bin/evince thesis.pdf
hansi    12352  0.0  2.1 1213492 171928 pts/2  Sl   Apr15   1:21 /usr/bin/evince thesis.pdf
hansi    12352  0.0  2.0 1213492 168492 pts/2  Sl   Apr15   1:22 /usr/bin/evince thesis.pdf
hansi    12352  0.1  2.0 1213492 168160 pts/2  Sl   Apr15   2:34 /usr/bin/evince thesis.pdf
hansi    12687  4.2  1.2 826684 98512 pts/2    Sl   22:12   0:00 /usr/bin/evince thesis.pdf

The VSZ (which includes libraries) grows from 827MB to 1213MB and the RSS grows from 97MB to 172MB and goes back to 168MB.

Interestingly the CPU usage is continuously going down within the first few minutes.

Now when Evince was really slow again, I investigated the behavior in more detail. A few pages were quite fast, but others were slow. I found out that only those pages which don't have section titles on them were slow. More precisely, pages without a link from the "Index" side pane (which I have activated all the time). I forgot to check the behavior with a different side pane or without any side pane before quitting Evince.

So, in short, pointers from the PDF bookmarks (I think that is the official name of what is shown in the "Index" side pane) make pages fast. If no pointers go to a page, this page will considerably slow down. I forgot to check whether pointers from other pages (with \ref{} or \pageref{}) also avoid the slow down.
Comment 4 José Aliste 2015-04-17 00:33:20 UTC
Thanks for the information. I think the last part is what is important. I remember seeing an intel document which has the same problems as you describe, or similar... I'll try to see If I can find the bug again... Last time I checked I was not able to fix it. Normally, if you don't have the Index Pane open, it should be fast. Could you confirm that?
Comment 5 José Aliste 2015-04-17 00:54:18 UTC
THis is the bug I am referring to in previous comment https://bugzilla.gnome.org/show_bug.cgi?id=735221
Comment 6 Johann Glaser 2015-04-17 10:22:27 UTC
So, now I've played with different side panes and without a side pane: Everything is fast except when using the "Index" side pane.

The bug is not exactly the same as that one you have mentioned. While my problem gets worse after every reload of the document, #735221 is slow from the beginning. But this is probably because my document only has 145 pages while the Intel PDF has 3463 and a much longer index. But the fact that it gets worse points to a specific and different problem.

After reading your comment for #735221: What speaks against using a reversed index memory structure, e.g., a key-value map page -> index item, which is built up when the document is loaded, or when the index is drawn the first time. Even for a 3463 pages document and an Int64 for the value (assuming a simple array) this is only approx. 23kB.
Comment 7 Johann Glaser 2015-06-25 11:43:37 UTC
This bug is still present in 3.16.1.
Comment 8 GNOME Infrastructure Team 2018-05-22 16:13:07 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/588.