When my hard drive failed, I was forced to use Porteus in RAM disk mode for a few weeks. I noticed that, whenever I double-clicked PDFs of DjVus, Okular started up very quickly, in a fraction of a second. But now that I am running off a hard drive, Okular loads much slower (at least 3-4 seconds). Why is this? What is slowing Okular down when run from a hard drive and not from a ram disk?

This delay has nothing to do with the type of files I open, because when I open another file (be it PDF, DjVu, etc.) within Okular, they load much faster than if Okular were not already launched to begin with.

It seems Okular slows down launching due to loading some library from the hard drive. How would I figure out which library is slowing it down?

do you also see the lag with pdf's? pdf's open pretty quick for me (I've no djvu's)

gonna guess that it's the djvu's being decompressed with the decompression occurring in ram instead of on disk and with ram being so much faster - but again just a guess

google01103 wrote:do you also see the lag with pdf's? pdf's open pretty quick for me (I've no djvu's)

gonna guess that it's the djvu's being decompressed with the decompression occurring in ram instead of on disk and with ram being so much faster - but again just a guess

I've updated the OP.
It has nothing to do with the type of file I open. I could start Okular directly, without loading a particular file, and it would still take just as long to launch.

additional info may help, versions of Distro, KDE and libpoppler? 32 bit or 64bit?

are you running KDE as your desktop?

has it always lagged? if not does it lag for a new user?

do other programs lag? if so which?

google01103 wrote:additional info may help, versions of Distro

slackware64-current

google01103 wrote:, KDE

4.10.5 (with Okular 0.16.5)

google01103 wrote:and libpoppler? 32 bit or 64bit?

poppler-0.24.3-x86_64-1 and poppler-data-0.4.6-noarch-1 (I'm not sure hwat that latter one is...)
(same as for Porteus in RAM disk mode and now with Slackware)

google01103 wrote:are you running KDE as your desktop?

yes

google01103 wrote:has it always lagged?

Yes, it has, ever since I first started using Slackware in 2010.

google01103 wrote:if not does it lag for a new user?

I thought it might be an issue with reading all the xml files I have for bookmarks, etc. (I have thousands), but the same launching delay occurs even for new users.

google01103 wrote:do other programs lag?

no

I do get this output when starting Okular:

Code: Select all

okular(5383)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(5383)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(5383)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(5383)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:

no idea about those messages

you could try upgrading, current KDE is 4.14.x, poppler is 0.26.x and Okular is 0.20.3 - Google'ing show a 3rd party Ktown repo with 4.14.x see http://alien.slackbook.org but as it's not an official repo you would need to use it at you own risk

also you can try running kdebugdialog -> deselect all -> search for okular -> select all -> ok then restart Okular and look at the tail end of ~/.xsession-errors for errors

google01103 wrote:you could try upgrading, current KDE is 4.14.x, poppler is 0.26.x and Okular is 0.20.3

Is KDE 4.14.x a major update?

google01103 wrote:also you can try running kdebugdialog -> deselect all -> search for okular -> select all -> ok then restart Okular and look at the tail end of ~/.xsession-errors for errors

That revealed a few more things (plus what I already posted above):

okular(25150)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-geremia/ksycoca4"
okular(25150)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25150)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25150)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25150)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(25150)/kparts KParts::ReadWritePart::setModified: setModified( false )
okular(25150)/kparts KParts::Part::~Part: deleting widget Sidebar(0x92d600) ""

The messages don't look like they are errors, none of which I experience
- the first one is explained here viewtopic.php?f=25&t=88152#p159577, no idea why you see it and I don't nor if would add to the time opening the app - I'd assume not

KDE 4.10.5 came out in July 2013 so it's a bit long in the tooth

don't know what you mean by "major update", it's an evolution of 4.x with added functionality and bug fixes, the most major things iirc since 4.10 would be the replacement of Nepomuk by Baloo and maybe changes to Akonadi (can't remember what or when).

you can check out the following to see what were supposed to be the changes
https://techbase.kde.org/Schedules/KDE4 ... ature_Plan
https://techbase.kde.org/Schedules/KDE4 ... ature_Plan
https://techbase.kde.org/Schedules/KDE4 ... ature_Plan

If you'd rather not upgrade, as 4.10.5 is std for Slackware, I'd suggest asking on their forum if Okular lags when opening, it would be useful to know if its isolated to your installation or not - all I can tell you is I don't experience any lag

So, contrary to what I previously thought, the launch speed is severely limited by the thousands of docdata files I have. I renamed the folder containing them, and Okular opened very quickly!

Geremia wrote:So, contrary to what I previously thought, the launch speed is severely limited by the thousands of docdata files I have. I renamed the folder containing them, and Okular opened very quickly!

Update: Actually, the launch speed is severely limited by "bookmarks.xml" (which is only about 400 KB on my machine), not the thousands of docdata files! Why would this be?

Why doesn't Okular just store bookmarks in the particular document's docdata XML file, that way the entire bookmarks.xml doesn't have to be scanned every time Okular launches?