Very Computer

Hi,

Why do Gnome apps (like Pan) startup much faster than KDE apps, using KDE
3.0.4 (on SuSE 8.1, i386)?

Should it not be the way around?

Cheers,

Jeroen

Because C++ programs start slower than C programs in Linux.  The problem
is well documented, and fixes are underway.  It is expected that the
fixes will be in the next major releases (point 0) of all the distro's.
It has something to do with the compiler, linker, and glibc.

There are some things you can do to somewhat relieve the problem,
including upgrading to KDE 3.1 (when released), and recompiling KDE
without any debugging info included.

Quote:> Should it not be the way around?

Given the above explanation, it actually works as it should.  If you
start KDE programs under Gnome, they will be even slower to start up.

Steve

Quote:> Why do Gnome apps (like Pan) startup much faster than KDE apps, using KDE
> 3.0.4 (on SuSE 8.1, i386)?

> Should it not be the way around?

Why, /precisely/, would you expect that?

The only reason to /imagine/ greater speed for KDE apps would be that
if you already have some KDE apps running, you already have some
shared libraries in memory.  

But there are some compelling reasons to expect KDE applications to
start up /less/ quickly than GNOME equivalents:
 - They have to start some additional daemons, notably DCOP;
 - Linking in the dynamic C++ libraries takes quite a lot of work that
   is not required for C libraries.  (vtables don't come for free!)
--

http://www.ntlug.org/~cbbrowne/kde.html
"Well, I wish  you'd just  tell me rather   than trying to engage   my
enthusiasm, because I haven't got one." -- Marvin the Paranoid Android

See this link for more info on the problem:
http://objprelink.sourceforge.net/

I'm not sure that distros haven't incorporated these changes already.

And I suspect while these changes will make KDE apps startup faster
than they did before, they may still not start up as fast as C apps do.

Steve

The major changes are part of glibc 2.3, which I don't think are in any
major distros yet.

Quote:> And I suspect while these changes will make KDE apps startup faster
> than they did before, they may still not start up as fast as C apps do.

Yes, C++ will (almost) always be slower than C.  This is a fact of how the
languages work.  But if they are made to perform close enough to each
other, then you may not notice the difference.

Steve

What changes are talking about, specifically?  Have a link?

Quote:>> And I suspect while these changes will make KDE apps startup faster
>> than they did before, they may still not start up as fast as C apps do.

> Yes, C++ will (almost) always be slower than C.  This is a fact of how the
> languages work.  But if they are made to perform close enough to each
> other, then you may not notice the difference.

C++ can be of course be faster than C in some applications, because of inlining
and function objects.  Here though we are just interested in the
dramatic difference in one particular type of performance - startup
time.  The tiny "extra overhead" of good C++ versus C is simply not enough
to explain the differences in start up time, IMHO.

I believe that KDE takes a performance
hit because it uses good OO design and reuses many classes through
libraries - meaning many, many symbols are exported, making lookups
slow.  Perhaps the fixes you refer to address this?

Another possible approach would be to follow what MS does with dlls -
only export symbols that are marked for export, therby improving lookup
speed.

Steve

Sorry, I read it somewhere, but I don't remember the link.  It mentioned
something about objprelink as being a hack, and the proper way to do it
was with combreloc (or something like that), and that had something to do
with a new glibc.

Quote:> I believe that KDE takes a performance
> hit because it uses good OO design and reuses many classes through
> libraries - meaning many, many symbols are exported, making lookups
> slow.  Perhaps the fixes you refer to address this?

Yes of course, this was what I was talking about.  It is possible to write
C++ code that doesn't use the slow C++ features.  I was specifically
talking about the Linux implementation of C++, where there is no caching
of symbol exports.  So every time a class is used, the work is done again
(and again).

KDE definitely does it the right way.  It's just that the C++
implementation in Linux is lacking.

Quote:> Another possible approach would be to follow what MS does with dlls -
> only export symbols that are marked for export, therby improving lookup
> speed.

I believe this was discussed as well.  If only I could remember where I
read about it :(

Steve

Here's something related to c++ and linux. Maybe this is what you mean.

http://www.suse.de/~bastian/Export/linking.txt