| Summary: | kpdf polls every second /proc/meminfo | ||
|---|---|---|---|
| Product: | [Unmaintained] kpdf | Reporter: | Georg Sauthoff <g_sauthoff> |
| Component: | general | Assignee: | Albert Astals Cid <aacid> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
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(). You are right. Still, in this case 'static int' implies '= 0' ;). Besides that, do you want to fix this polling? The polling is sort of needed, otherwise your KPDF cannot adapt its memory usage to the current available memory. 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 > 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. > 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.) > 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. 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? |
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