[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: some thoughts on libkio
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-12-07 11:19:48
[Download RAW message or body]

On Tue, 07 Dec 1999, Cristian Tibirna wrote:
> On Mon, 6 Dec 1999, Stephan Kulow wrote:
> 
> > Simon Hausmann wrote:
> > > 
> > > So if I understood Waldo's mail correctly, then each KIOJob tries to
> > > connect to that one running kio_slave daemon process (or start it on
> > > demand, if not available/running) . That kio_slave process then forks and
> > > loads the protocol implementation as shared library.
> > > 
> > > (hmm, I guess I must have misunderstood sth., as otherwise the current
> > > concept looks more lightweight to me (note that the current kioslaves
> > > don't create a [Q/K]Application object) .
> > 
> > They don't need to in Waldo's concept either.
> > 
> 
> Or perhaps, instead of a daemod for each type of slave, use the inetd
> concept?

Basically there is not much wrong with the current kio-slaves. However,
and this is something which affects all Qt/KDE applications, we have a
quite significant per process memory overhead due to the dynamic ELF
linker: Each KDE process which we start with exec() needs about 400K of
memory which gets initialized with pointers into our libraries. 

E.g. konsole takes about 250K for the data segments: all vtables of all
the classes in the libraries are put into this, they need to be
initialized with the adrresses of the methods taking into account the
actual load address of the shared library. 

Another 100K is needed for the got segments (Global Offset Table) I
haven't figured out what this does exactly.  And yet another 100K is
wasted on small stuff.

I have made a script which looks up which libraries an executable uses
and then adds up the various non-shared segments of all these libraries.
E.g. "./meminfo konsole" shows how much non-shared memory konsole needs
for its libraries. "./meminfo konsole data" shows how much non-shared
memory konsole spends on ".data" segments.

You can do "objdump --syms $KDEDIR/lib/libkdecore.so.3.0.0" and grep
out e.g. the data segment with "grep -e "O .data" to see what is
actually stored in these segments.

It's quite nice to give each task its own process. If one task crashes
it doesn't take half of the desktop with it. This library overhead is
currently one of the major drawbacks to actually do that.

If you start konsole 5 times you have this overhead 5 times. However,
if you start konsole 1 time, and then fork it 4 times, you have this
overhead only once. (I still haven't verified this though.)You can do
the same with io-slaves. 

The big question is now whether we want to introduce such work-arounds
or whether we should try to attack this library overhead in the first
place.

Cheers,
Waldo



["mem_info" (application/x-shellscript)]

#!/bin/sh
exe=`which $1`
section=got
#grepexp=' \.'$section
if [ x$2 == "x" ]; then
  grepexp=READONLY;
  grepflag="-v";
else
  grepflag="";
  grepexp=" .$2";
fi
totalsize=0
ldd $exe | sort -t '=' +1| while read i; 
do 
  lib=`echo $i | cut -d ' ' -f 3`
  address=`echo $i | cut -d ' ' -f 4`
#  echo Lib = $lib, address = $address
  objdump --headers $lib| grep -A999 "Sections:" | while read h;
  do 
    read d;
    echo $h $d
  done | grep $grepflag -e "$grepexp" | grep -v "Idx" | while read l;
  do
    size=`echo $l | cut -d ' ' -f 3`
    section=`echo $l | cut -d ' ' -f 2`
    dsize=$[0x$size]
    echo $section $dsize $lib 
  done 
done | while read l;
do
    dsize=`echo $l | cut -d ' ' -f 2`
    totalsize=$[$totalsize + $dsize]
    echo $l $totalsize
done


[prev in list] [next in list] [prev in thread] [next in thread]