Re: some thoughts..

[Andreas Kostyrka <andreas rainbow studorg tuwien ac at>]

On Wed, 6 May 1998, Timo Sirainen wrote:

> > > These extensions probably use a lot of memory to do things which usually
> > > aren't done all the time, so it just uses megs of totally useless memory
> > > most of the time. This seems to be the problem with whole KDE, it takes
> > > over 11 megs of memory (+shared 2-5MB?) to do things I mostly don't need.
> > > Solutions? I can think of some:
> > As long as the code isn't used, all you loose is the memory allocated to
> > the page tables. (Linux does on demand paging of executables.)
> 
> I can't really believe this works well. Well, maybe if the application is
> build so that Linux knows right what code is used, but for example
> netscape and kde, why do they take so much memory and don't work well
> with computers with low memory? They use all their code and do "if
> (!do_i_need_to_do_something()) return" type things everywhere? I don't
> know, but I'm sure I haven't used any sounds and still KDE's sound servers
> eat megs of memory.
1.) The soundserver is still started.
2.) The soundserver still waits for requests.
3.) The soundserver still tries to process requests.
So the soundserver is practically used as a whole.

One additional thing is, that KDE is 99% C++, and C++ has a tendency to be
a memory hog. (tempates need memory during compilation, AND during
runtime, as array<char *> and array<void *> do have usually two different
function sets generated. GList's one the other hand have their code once
in the system.)

> Shared libs are loaded entirely to memory or just parts of them? (should
> some of them be divided into smaller libs?) And do you mean that they are
Shared memories are mapped as a whole into the address space. They are not
loaded. Then the app is started, and when it tries to access a library
code page, then Linux page faults and fetches the code.
> not even loaded or that they are loaded to memory and possibly placed to 
> swap?

> Well, at least you need to have some wrapper functions because you can't 
> directly use gtk_() functions.. ok, not much :) And I don't know about
> gmc's code but I just had some feeling that if program works in text mode,
> X, windows, etc, it must have useless code..
It probably has some unused code in the source. (It's still not useless.)
And gmc uses the gtk functions directly. It just uses mc's backends to do
it's job.
> 
> > Again. If it is not needed, the gmc code is not in memory, and the
> > unneeded data lays in swap :)
> 
> But my swap gets full... ;)
Get more swap.
Additionally, breaking the icon parts may result in the following numbers
(just guesses from myself):
gmc   100 units memory
versus
icons 60 units memory
gmc-icons 70 units memory
sum=>130 units memory.

So while a icon program could (at least in theory) use less memory, the
memory used by the icon program, gmc, and the communication routines
between the two will be greater.

Andreas