glib dependancy in KDE3.x

[Stefan Westerfeld]

   Hi!

On Fri, Mar 07, 2003 at 07:06:24AM -0800, Neil Stevens wrote:
> > How big is GLib?
> >
> >  I've seen people here use the word "tiny" to refer to GLib.
> >  To avoid unpleasant surprises ... no it isn't tiny. Compiled
> >  libglib is ~400k and libgobject (if used) about ~200k more.
> >  But if you aren't using, say, the Unicode normalization tables,
> >  they should stay on disk.
> 
> ... now we're told glib is large.  This is not encouraging at all.
> 
> >  (And if there is another program already running using GLib,
> >  then any GLib overhead is shared.)
> 
> aRts would be the first to use glib, and the use of aRts by knotify and 
> konqueror would assure that every KDE user was having to load glib on KDE 
> startup.

Linux (or Unix in general) is using extremely clever memory management to try
to ensure that only those pieces of code/data are loaded into memory and
remain there, that really need to be there.

Thus, its not as if libraries are loaded (as one file) into memory. Instead
the loading process works something like this:

(1) you create a virtual adress space for each program
(2) in this virtual adress space, you mmap(2) all components of the program
    you need at appropriate locations
(3) finally, once you have done this, you simply run the program without
    loading the libraries

Now how does it work, then? The answer is simple: once the instruction pointer
gets into a page that has not been loaded already (for instance because some
other program links against the same library), the memory management unit
generates a page fault.

This page fault is handled in the kernel, where the VM decides how this page
can be provided. Usually, the page can be found already in the "cache", which
is just another way of saying that it has been loaded previously, but nobody
used enough other memory so that the linux kernel saw the necessity to throw
it out.

So lets try to apply this to the question of wether or not "glib is large" is
bad for us:

We know that a lot of applications written in C use glib already. In fact, its
unlikely to find a linux system where there is no gtk+ application installed
that the user wishes to use. So the parts aRts is probably going to use would
already have been loaded. Even if there is no single gtk+ application that the
user wishes to use, there is no loss in either case.

Currently, aRts already has implementations for the things it wants to use
glib for. The code size of these is probably approximately the same size than
the code size of the glib implementation. So we already force everybody to
have pages of this total sum in memory, because we do use aRts. The only way
to lessen the burden to the user would be to improve codesharing between aRts
and Qt.

That is possible in the following ways:
 - depend aRts on Qt
 - depend Qt on glib

I think if we were to evaluate these two alternatives carefully, we would
find that the second is more beneficial, because again its unlikely that a
user only uses Qt applications, but not applications using Gtk+. And such a
user would suffer from serious problems, because he has committed himself
to a policy of using only a certain subset of applications, that don't ideally
span the area of what free software provides.

In fact, I am convinced that some things should be implemented in C. And I
am convinced that some things are implemented best using a main loop. Thus
I'd say that a user which commits himself to the irrational policy of using
only C++ applications and only C++ code, for the sake of attaining some
higher goal that I don't know of, should not be supported optimally by KDE.

We only should support those users optimally that want to use whatever free
software is best for the job, without religious attachments to what language,
race, country, free software project, ... is best for the world.

I think KDE should promote tolerance and understanding where we can, and this
is a place where we can promote understanding of what programming languages
and code sharing are really for.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-