Bug 150325 - kpdf polls every second /proc/meminfo
Summary: kpdf polls every second /proc/meminfo
Status: RESOLVED FIXED
Alias: None
Product: kpdf
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Albert Astals Cid
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-29 14:47 UTC by Georg Sauthoff
Modified: 2007-11-10 20:57 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Sauthoff 2007-09-29 14:47:40 UTC
Version:            (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages
OS:                Linux

Hi,

while strace'ing kpdf I noticed that kpdf polls every second /proc/memtime.

The problem seems to be this code:
int KPDFDocument::getTotalMemory()
{
    static int cachedValue = 0;
    if ( cachedValue )
        return cachedValue;
   // [1]
   // some /proc/memtime reading - expensive - code

Well, the [1] part never gets executed because at every function entry cachedValue is set to 0. If you declare a variable as static inside a function the C/C++ standard specifies, that it is initialized with 0.

Best regards
Georg Sauthoff
Comment 1 Pino Toscano 2007-09-29 15:24:41 UTC
You're wrong here: the static variable is initialized only once, i.e. the first time the function is called.
You picked the wrong function, as what really polls /proc/meminfo is getFreeMemory().
Comment 2 Georg Sauthoff 2007-09-29 15:37:55 UTC
You are right. Still, in this case 'static int' implies '= 0' ;).

Besides that, do you want to fix this polling?
Comment 3 Pino Toscano 2007-10-06 14:07:26 UTC
The polling is sort of needed, otherwise your KPDF cannot adapt its memory usage to the current available memory.
Comment 4 Pino Toscano 2007-10-06 14:09:32 UTC
SVN commit 721994 by pino:

Wait at least 2 seconds before reading /proc/memory again.

BUG: 150325


 M  +10 -1     document.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=721994
Comment 5 Georg Sauthoff 2007-11-10 20:00:52 UTC
> The polling is sort of needed, [...]

Well, there is a 'movement' to write programs, that do not wake up all the time to save energy. Specially a good idea when on battery. See for example:
http://www.lesswatts.org/
http://udrepper.livejournal.com/19041.html

Perhaps only checking /proc/meminfo at startup and choosing a sane default is an alternative. I mean, other complex programs do fine without trying to be extra 'smart' about /proc/meminfo.

Just a thought.
Comment 6 Pino Toscano 2007-11-10 20:26:50 UTC
> Perhaps only checking /proc/meminfo at startup and choosing a sane default is an alternative.

Sorry, it's not.
What if I start KPDF when I have let's say 500MB of free memory, then I start "heavy" applications (eg OpenOffice.org, kontact, etc)?

> I mean, other complex programs do fine without trying to be extra 'smart' about /proc/meminfo.

Other complex programs needs to care at their memory usage like KPDF?

> Well, there is a 'movement' to write programs, that do not wake up all the time to save energy. Specially a good idea when on battery.

Well, and there's a movement of reopening bugs without even checking if the behaviour of application is really a problem.
After this bug fix, a single KPDF instance with an open document causes *less than one* wakeup per second (measure taken with powertop, noticing how 5 KPDF instances causes ~4 wakeups per second).
I find less than one wakeup per second more than acceptable, thus this bug is FIXED. (Without counting that reopening bugs with no single proof of problems, is not a smart thing either.)
Comment 7 Georg Sauthoff 2007-11-10 20:47:31 UTC
> Other complex programs needs to care at their memory usage like KPDF?

yes, of course.

> I find less than one wakeup per second more than acceptable, thus this bug is FIXED. (Without counting that reopening bugs with no single proof of problems, is not a smart thing either.)

well, keep it easy. Reopening a bug, because you have new information is good enough in general. Just giving a statement and re-closing it doesn't cost much more, than just giving a statement.

The next time slot I have free, I measure this polling-issue. I.e. how much kpdf instances costs how much watt and how big is the system overhead. I mean, at my laptop 10 open pdfs are total normal and just think about some Xterm/Sunray setups where you have easily > 30 users at one machine.
Comment 8 Albert Astals Cid 2007-11-10 20:57:03 UTC
As a comment on why KPDF needs to manage memory probably more than others, a typical A4 at 100% zoom is about 595*842 pixels which means 1.9MB of memory, now open a 1000 page pdf (i have some) and if we don't free memory we will take about 2GB of RAM only for the pixmaps, more if you start a text search. So of course, we could make KPDF use someArbitraryNumber MB of RAM as a maximum, but i see this as a limitation, because some people may have 4GB of RAM while others may have only 256MB so if we set a 60MB limit the 4GB person won't be happy and if we set a 1GB limit it'll crash/hardSwap the 256MB users.

So besides saying we are doing "a bad thing"(tm) can you suggest how to deal with that issue?