Dear Maintainer, Searching (aka. 'Find') a larger pdf-document (1326 pages 11 MB) with a short search string from beginning of the document to the end used to take 22 seconds on my laptop with the squeezy version of okular (okular 0.10... debian 4:4.4.5). After a dist upgrade to debian wheezy (with okular 0.14.3 debian 4:4.8.4) I noticed the same search slowed down to somewhat over a minute. That's a slowdown by almost factor three. Shouldn't new software generally run faster? It's annoying as I use searching larger pdfs rather frequently. I noticed (using xosview) the old okular was running the search on a single CPU core while the newer one is using both CPU cores I have. This means the total used CPU time increased by factor 6! I understand that parallelizing an algorithm some tradeoffs have to be made, but factor 6 is absolutely unacceptable. I understand that on an 8 core the new parallelized search might require less wallclock time, but I *CANNOT* accept 'by an 8 core' as a bugfix. The problem might very well reside in one of okulars library packages. -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages okular depends on: ii kde-runtime 4:4.8.4-2 ii libc6 2.13-38 ii libfreetype6 2.4.9-1.1 ii libjpeg8 8d-1 ii libkdecore5 4:4.8.4-4 ii libkdeui5 4:4.8.4-4 ii libkio5 4:4.8.4-4 ii libkparts4 4:4.8.4-4 ii libkprintutils4 4:4.8.4-4 ii libkpty4 4:4.8.4-4 ii libokularcore1 4:4.8.4-3+b1 ii libphonon4 4:4.6.0.0-3 ii libpoppler-qt4-3 0.18.4-5 ii libqca2 2.0.3-4 ii libqimageblitz4 1:0.0.6-4 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-svg 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsolid4 4:4.8.4-4 ii libspectre1 0.2.7-2 ii libstdc++6 4.7.2-5 ii phonon 4:4.6.0.0-3 ii zlib1g 1:1.2.7.dfsg-13 Reproducible: Always Steps to Reproduce: 1. Open a large PDF document, say ISO C++ 2011 standard as PDF. 2. Type Ctrl+F to start a search. 3. Enter a search string that will run thru the hole document, say 'grumpf'. Actual Results: see 'Details' Expected Results: see 'Details' see 'Details'
Dear user, i can not accept a bug against a software that is 2 versions old and that does not include a pdf to test, please update to the newest version of okular (0.16.x) and if the slowdown is still reproduceable reopen this bug.