[kde-solaris] KDE 3.2.*, Solaris 9,
and other news [ was: swap space requirements ]
steleman at nyc.rr.com
Tue Jan 27 02:29:51 CET 2004
I'm back at home, thus i can post some more. :-)
On Monday 26 January 2004 10:47, Philippe Bourdeu d'Aguerre wrote:
> > a) shrink KDE
> Is it impossible ? I notice that when I launch an application from
> a shell there are lot of debug output. Is it possible to suppress
> them ? With Linux-Mandrake there is no such output.
I believe it is possible to shrink KDE somewhat. This little
explanation below is going to be a little long, tedious and boring,
so, if you don't feel like being subjected to it, please feel free to
stop reading. :-)
IMVHO opinion, there is one main reason for the RSS and PS sizes
described by Lars: KDE makes very extensive use of dlopen() with
RTLD_NOW (which means, resolve and bind all symbols at load time).
Not only that, almost all processes started from within KDE are
started by kdeinit which then fork()'s (which explains the presence
of so many kdeinit's being swapped out). The dlopen()/RTLD_NOW trick
has some advantages, by giving a performance boost (no need to
resolve and load symbols run-time). It was also implemented because
of gcc and the problems with the GNU run-time loader which could not
(still can't ? -- i hear the situation is improving) do symbol
Disclaimer: i am not criticizing KDE by any means. I am only
describing some aspects of its internal architecture.
So, in theory, all this dlopen() stuff could be safely removed from
Solaris KDE, because the SunOS run-time loader has no problems
relocating symbols. But this would require one of the following
- create a separate source code branch for KDE Solaris (which would
probably work, but it's not a Good Thing To Do by any means) -- it
makes source code upgrades and patches between releases a complete
- keep only one branch, but fill the code with #ifdef's -- guaranteed
to make the code incomprehensible and unmaintainable within 6 months,
and also guaranteed to be veto'ed by kde-core-devel
- remove all dlopen()'s completely, which runs the risk of breaking
KDE on GCC, and also requires some significant rewrites in kdelibs
The other aspect is: being written in C++, KDE binaries will incur a
size overhead because of the exception mechanism, if nothing else. I
can disable exceptions at compile-time, but that is not a good idea.
The only way of guaranteeing that something does not throw, is to
declare it with a throw() exception signature. Neither KDE nor QT
declare exception specifications in their method signatures, so,
anything can throw. In the unfortunate case that something throws,
but the exception mechanism was disabled at compile-time, the
behavior is undefined, and it is also close to impossible to debug,
or even track down.
And now, you can flame me. :-)
OK, now for the news:
I have gotten my hands on a second Ultra60 box (2x450 UltraSPARC II,
2GB RAM Elite 3Dm6 :-), and i installed Solaris 9 on it. Which, for
the purpose of working on KDE, is Da Bomb. I was trying to get an
UltraSPARC III box, but, to paraphrase someone else's post on a
different newsgroup, these things cost an arm, a leg and the original
Mona Lisa, even refurbished. I am now working on 64-bit KDE, and i
have started by working on those required 90+ little libraries last
weekend. I cleared a major bump this weekend when i got 64-bit NAS to
work. I am building for v9a. I am hesitant, at this point, to give a
precise timeframe as to when the whole 64-bit port will be finished,
but i just wanted to let everyone know that i am indeed working on
it, as of January 17. When it's done, it will be only for Solaris 9.
As far as KDE 3.2.* goes: i'd like to wait until the first 'official'
release is out before i start working on it (32-bit and 64-bit in
Stefan Teleman 'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com -Monty Python
More information about the kde-solaris