Hi all,

Just opened a newly downloaded pdf book with okular, and all of a sudden a pdftotext instance is started, taking up over 50% of my CPU use. Closing okular didn't stop it, so I assume this is nepomuk indexing the thing. Very nice tech, but on my old pentium 4, everything grinds to a halt this way, and I suspect my netbook won't fare any better. Can any of you confirm what this behaviour is about, and how I can avoid it (or speed it up, or shove it into the background, preferably automatically, don't want to go renicing everything every time I open a pdf). Oh, yeah, 4.5.1 on kubuntu 10.10, ancient P4 2.4GHz, 2Gb RAM and an Nvidia 7600GS card.

you can add an alias in your .bashrc file "alias pdftotext='nice pdftotext' which should effectively resolve your performance issue automatically. Untill I up'ed to a dual core I had a done this with a number of apps like lame, cc, gcc, make.

someone might correctly me on the most effective file to place it in

Unfortunately other than disabling all applications which use libstreamanalyzer there is no way to do this, as pdftotext is called by libstreamanalyzer itself directly. Strigi uses libstreamanalyzer to provide it's indexing capabilities.

Excluding *.pdf files from being searched in System Settings > Desktop Search should be sufficient to do this.

bcooksley wrote:Unfortunately other than disabling all applications which use libstreamanalyzer there is no way to do this, as pdftotext is called by libstreamanalyzer itself directly. Strigi uses libstreamanalyzer to provide it's indexing capabilities.

Excluding *.pdf files from being searched in System Settings > Desktop Search should be sufficient to do this.

There seems to be more going on than this: Strigi indexing was off already, so excluding pdfs doesn't do the trick (but I did it anyway). Another anoying thing: pdftotext continues after I close okular, and even when I kill it, it keeps popping up again and again. Even if I kill it as root, and with killall Any ideas on this?

Ok, the above doesn't make sense. These pdftotext instances can't just pop up out of nowhere, so there had to be some overlooked open process generating them. The answer is quite obvious: dolphin was still open with the big-ass pdf book I opened earlier selected. So it must be dolphin's pdf previewer which is the culprit.

Also, I tried putting alias pdftotext='nice pdftotext' in .bashrc and .bashprofile like google01103 suggested, but that doesn't seem to do much. How do I get processes started by kde apps to heed these rules? Or do I just have to shut off the pdf previewer in dolphin? That would be a pity, I like all of the new kde tech like indexing etc, but it seems to require somewhat heavier hardware than what I'm using at the moment.

Edit: Turning of pdf previews in the dolphin settings doesn't change a thing, it still starts a pdftotext process. It shouldn't have generated a preview in any case, since it was set not to preview for files over 5Mb, and the book is 15Mb. Puzzled here...

thoughts: (try #4 first)

1) try "nice -19 pdftotext", running system monitor shows pdftotext is running at the requested niceness? note: won't reduce cpu usage but should make other apps run better

2) 2gb should be more than enough ram but run "free" to see if the problem is swap disk being used instead of ram

3) run "iotop" to see if excess disk access is causing the grinding

4) what is Okular -> settings -> configure Okular -> Performance -> Memory Usage ? try normal if set to aggressive

5) do you have other indexers installed and running other than strigi? recoll, beagle, Geoogle desktop search, Tracker?

6) maybe silly q but if you kill Okular the pdftotext process disappear?

google01103 wrote:thoughts: (try #4 first)

1) try "nice -19 pdftotext", running system monitor shows pdftotext is running at the requested niceness? note: won't reduce cpu usage but should make other apps run better

I put "alias pdftotext='nice -n 19 pdftotext'" in both .bashrc and .bash_profile. The pdftotext instance which is started automatically remains at priority 20. If I run pdftotext from the command line, it runs at priority 39, so I guess the bash config files are not the right place to put this.

google01103 wrote:2) 2gb should be more than enough ram but run "free" to see if the problem is swap disk being used instead of ram

Ok. No swapping going on.

google01103 wrote:3) run "iotop" to see if excess disk access is causing the grinding

Seems to be negligible.

google01103 wrote:4) what is Okular -> settings -> configure Okular -> Performance -> Memory Usage ? try normal if set to aggressive

Okular is set at normal. But okular doesn't start the pdftotext instance (maybe I should change the thread title?), dolphin's the culprit.

google01103 wrote:5) do you have other indexers installed and running other than strigi? recoll, beagle, Geoogle desktop search, Tracker?

Nope.

google01103 wrote:6) maybe silly q but if you kill Okular the pdftotext process disappear?

See above, but to answer your question in an updated context, yes if I kill dolphin, pdftotext disappears (with some delay). For a more detailed account of its behaviour: when I open a folder with pdfs in it, using icon and preview view, it starts a short lived pdftotext instance. When I mouse over a pdf file, it does the same. When I select a pdf file, it starts a pdftotext instance which keeps running all the time. Killing it spawns a new instance, unless I shut down dolphin. All these instances run at priority 20. Strangely enoug, I turned off previews of pdf, ps and dvi files in Dolphin Preferences->General->Previews, and the default settings don't allow previews for files above 5MB anyway, but the behaviour still persists.

re: nice - nice actually goes, per the man page, from -20 -> 19
I misremembered the command syntax, the "-nn" adds to the current nice value (default of 10)

If you use Krusader instead of Dolphin as the file manager do you see the same problem?

google01103 wrote:re: nice - nice actually goes, per the man page, from -20 -> 19
I misremembered the command syntax, the "-nn" adds to the current nice value (default of 10)

If you use Krusader instead of Dolphin as the file manager do you see the same problem?

Krusader doesn't start any pdftotext instances, even if I switch on preview.

What about Konqueror?

bcooksley wrote:What about Konqueror?

Nope. No pdftotext. Not while hovering, selecting, and even opening the file. Seems to be dolphin only.