GNOME Bugzilla – Bug 732404
High CPU usage (around 100%) when selecting text
Last modified: 2017-07-10 11:49:44 UTC
If I open gnome-system-monitor (on "Resources" tab) on half of the screen, and in the other half I open evince and view a PDF file, then I can notice a high CPU usage during the selection of text. To reproduce: 1) Open gnome-system-monitor (on "Resources" tab) and evince (open a PDF with text) 2) Start selecting a line of text, move your mouse slowly (to the right, then to the left, selecting and deselecting the same line of text) 3) You should notice a high CPU usage I'm able to reproduce this bug on these configurations: * ArchLinux, evince 3.12.x * Fedora (rawhide), evince 3.13.x
I cannot reproduce it. does this happen with any PDF in your machine or with a specific one? If the latter, please attach a test case.
Any PDF. I will try to record it and upload it on youtube.
Here is the video of the bug https://www.youtube.com/watch?v=54x53Hc__6M It shows the difference (in CPU usage) between selecting text in chromium and evince. I had to use a phone to record it, because the screen recorder was skewing the CPU usage.
I am afraid there is not much we can do, except, trying to optimize a bit text selection. selecting text in pdf is something a bit expensive, and the current code path to render it also I would guess.
*** Bug 756366 has been marked as a duplicate of this bug. ***
William, actually I believe this bug was fixed in latest version of git master (and the fix will be available in 3.18.1). Can you check with newer version of evince if you can still reproduce the bug?
Mmmm.. I just tried with evince-git from AUR (cloned and compiled) and the bug seems to be still there.
I've noticed something similar but I'm not sure if it's the same issue or not. The problem is that when there is a selection there is very high CPU usage. It doesn't have to be a large selection either, just one word will do it. And I don't have to keep selecting/deselecting like the video; just select the word and CPU usage skyrockets. After evince, Xorg and gnome-shell consume a lot of CPU too when this happens. Similarly, I notice high CPU usage when there are find results highlighted. I search for something (it doesn't matter if it's common or not, but we need at least one match to trigger it) and after the search is finished, the CPU usage is very high. This one is a bit different from the previous in that the CPU usage is high in Xorg first (~40%), gnome-shell second (~30%), and evince third (~17%). Once I click the "X" to close the search bar everything goes back to normal (less than 1%). I have tested this with different PDFs. Evince version is 3.18.0 (I use Arch too).
William I think that evince-git from AUR still does not have https://git.gnome.org/browse/evince/commit/?id=1987f04ea36329b1bd61d053a19d9e341e0454ce Pavlos, the bug you are mentioning was fixed in the commit I just pointed to. The fix will be in 3.18.1
The evince-git from AUR is currently based on commit: ec0faabdd952652b3c65981ef47fef00dd6a62c4, and if I do `git show 1987f04ea36329b1bd61d053a19d9e341e0454ce` I see the commit you mention, so I think it was included... just compiled and tested again to be sure and the bug is still there.
Ok, thank you for confirming, I just wanted to be sure it was a different bug.
William, actually I can't reproduce your bug. Could you use sysprof to try to see what's happening? Using sysprof should be fairly easy, just make evince to go high cpu while getting data from sysprof for a long time (one or two minutes) and ensuring your computer is not doing something else. That should allow us to see where are these extra cpu cycles going.
José, I think the CPU usage increases but Evince is still quite responsive. I mean, I can see an increase in the CPU usage after a while, if I did not monitor it, I would not notice it.
Germán, that's exactly what I mean with "I can't reproduce the bug". Actually the cpu is increasing in my computer because of the other high cpu selection bug... but this bug is about cpu near 100% so i want to see if there is anything in particular that is affecting william and not affecting me or you. :)
Created attachment 313928 [details] Output of: valgrind --tool=callgrind evince I tried profiling with valgrind. I attach the output of the execution. This is a screenshot of kcachegrind showing the profile data: http://i.imgur.com/UuG534M.png So it looks like the cuplrit might be the I/O. There seem to be a lot of calls to libgio (input/output?) and libz (compression?). Maybe everytime you select the text the PDF is read again? :P
can you attach the pdf file you were testing with? I think the text is somehow compressed inside the pdf and yes... I don't think poppler does a cache of the uncompressed text.
Created attachment 313943 [details] The PDF file used by evince (when using valgrind) Here it is
Today I tried to reproduce again this bug, and it looks like it's still there (CPU goes easily over 80% usage when selecting). I tried to measure function calls with perf top: When the PDF is opened: http://imgur.com/MhXUCRi After selecting for some time: http://imgur.com/N894kdW So it seems that the culprit is mostly in these libpoppler function calls: FlateStream::compHuffmanCodes FlateStream::getHuffmanCodeWord and also (in minor part) in: FlateStream::readSome FlateStream::getChars
Those are poppler functions. I cannot reproduce the issue with poppler 0.47.0. William, may you try with an updated poppler?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!