Slow xfrun, [was: new dev branch stuff]

[edscott wilson garcia]

El jue, 20-01-2005 a las 07:56 +0200, David Fraser escribió:

> 
> The interesting thing here is that the decision about sacrificing RAM 
> for speed may depend on how much RAM is available. So if all the 
> developers have lots of RAM, they may find that they can speed things up 
> by using lots of it, but on an old system (like the Linux lab that I set 
> up at my church) this may in fact slow things down.
> An example is parsing XML files and storing caches of them. I often 
> wonder whether a better design can avoid the decision altogether :-)

Which brings us to the "xfrun is awfully slow" reports. 
Yes, it is true. Xfrun can be awfully slow. Read on.

Today I fired up xfrun after 12 hours of no interactive use and took
time. Xfrun took thirty seconds to appear on screen, *no kidding*. I
closed the window and fired it up again and the response was almost
immediate. Let's take a look at the diagnosis:

system memory use: 252 MB
system swap use: 145 MB
system free memory: 4 MB

xfrun executable size: 247 KB
xfrun virtual memory requirements: 7.056 MB
xfrun resident memory size: 7.056 MB
xfrun shared memory: 5.184 MB

Which leave approx. 2 MB of non-shared. 

Where's all that memory above the 247 KB mark coming from? 

libdbh-1.0.so -> 23 KB
libxfce4_combo.so.0.0.0 -> 213 KB
libxfce4util.so.1.0.5 -> 514 KB
libxfcegui4.so.3.0.3 -> 7 MB
libglib-2.0.so.0.400.8 -> 569 KB
libgtk-x11-2.0.so.0.400.13 -> 3.3 MB
 
So, after a 12 hour inactivity period, with memory consuming cron jobs
at 3 AM, these shared libraries are sent to disk swap and must be reread
(at least 5 MB).  That causes a performance hit. It seems to me
libxfcegui4 is a bit too big (twice the size of libgtk). Maybe the
library can be split into smaller libraries. Maybe the two small
routines used by xfrun could be simply cut-n-paste into the executable.

Any other explanation as to why xfrun is painfully slow for certain
users?





-- 
edscott wilson garcia <edscott at xfce.org>