Bug 316483 - extreme slow down of search in version of wheezy compared to sqeezy
Summary: extreme slow down of search in version of wheezy compared to sqeezy
Status: RESOLVED NOT A BUG
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.14.3
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-10 18:30 UTC by Thomas Zoschke
Modified: 2013-03-10 19:31 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Zoschke 2013-03-10 18:30:02 UTC
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'
Comment 1 Albert Astals Cid 2013-03-10 19:31:33 UTC
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.