Slow xfrun, [was: new dev branch stuff]

edscott wilson garcia edscott at
Thu Jan 20 16:34:37 CET 2005

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? -> 23 KB -> 213 KB -> 514 KB -> 7 MB -> 569 KB -> 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

edscott wilson garcia <edscott at>

More information about the Xfce4-dev mailing list