JUL
17
2002

OSnews: Interview with Waldo Bastian

OSnews is running an
interview
with the dot's very own
Waldo Bastian.
Besides his long-running contributions to a large range
of the KDE libraries and other desktop infrastructure, Waldo is
well known as the KDE 2 "release dude", for helping keep the KDE
infrastructure operating, and as an inexhaustible supply
of knowledge and tips to other developers on IRC. In his at times
serious and at times tongue-in-cheek interview,
Waldo talks about the growth of Linux, his employer
SuSE,
GNOME competition and cooperation,
the role of
UnitedLinux, and KDE's performance,
and also reveals a secret way to get
Trolltech
to add requested features to Qt: "Catch a live Troll, lock it up
and feed it beer till it promises to make whatever you need.
"

Comments

I can't think of how many times I have had people email me and say the were not able to help develop an open source project. Waldo has put it so succinctly... send beer. ;-) I think I'll have one now.

I want to take a moment to express my appreciation for Waldo as well as so many other key core developers who make so much happen. It is always fun to see such great people at work and play on KDE.


By Eric Laffoon at Wed, 2002/07/17 - 5:00am

What I have liked the most:

"I'm looking forward to the day when this new linker is widely in use because then it will become painfully clear where the linker was causing the slowness and where it is solely to blame on the application developer. At the moment it is much to easy for developers to shift the blame on the linker."

So true. Very interesting interview. Worth reading it!!!


By Anonymous at Wed, 2002/07/17 - 5:00am

Now for the real question: When will a "prelinked" KDE be the standard? Are we weeks, months, one year, several years away? I'm waiting for the day when a new Mandrake, SuSE or Red Hat comes with KDE prelinked right out of the box.


By matt at Wed, 2002/07/17 - 5:00am

As soon as gcc releases their new compiler/linker. The problem is not in KDE, it is with gcc, and only affects anybody who has used gcc to compile KDE. Since gcc is all over the place, and by far the most common compiler used on Linux and BSD, the problem affects most users of KDE.

--
Evan


By Evan "JabberWok... at Wed, 2002/07/17 - 5:00am

What you said is true, but the question I previously sent and would like to get an answer if possible is:
How much of the start time can be reduced with an improved linker?
Will apps boot twice faster? Three times faster? 20% faster?
I'd really like to know what are we waiting for when we hear "Just wait until the linker is optimized and apps will boot faster"
Thanks guys


By Anonymous at Wed, 2002/07/17 - 5:00am

I have some (old) data on http://www.suse.de/~bastian/Export/linking.txt
Be aware that these numbers depend on the actual version of KDE/Qt (they will become slowly worse when KDE/Qt grows), the number of libs used by the application and your CPU (they will become better with faster CPU / faster memory)

In short: KEdit takes about 1.3 seconds to start and about half of that was caused by linker overhead.

Keep in mind that kdeinit already reduces most of the linker overhead, so applications that currently run as "kdeinit:" are unlikely to see any benefit at all.

Cheers,
Waldo


By Waldo Bastian at Wed, 2002/07/17 - 5:00am

A "ps -aux" on my system shows me that almost all KDE progs are run as kdeinit.
Konqui for instance is run as kdeinit.
Then, after all, I understand the problem is not on the linker. Konqui still needs almost 3 secs on a 1Ghz intel to boot even if it has been previously opened.
Should we expect any improvements, or is this speed considered good enough?

Thanks Waldo and KDE developers.


By Anonymous at Wed, 2002/07/17 - 5:00am

Hmm, how was your Konqui compiled? I could produce times of about 1-1.5 seconds for optimized builds with my Celeron 950.


By Sad Eagle at Wed, 2002/07/17 - 5:00am

It was compiled by RedHat.

Don't tell me that I should compile by myself when KDE project is all the time saying that configuration tools, for instance, depend on the distribution.

So I do have to get a distribution to get the config tools, but then I have to compile it by myself?

Or is it just that KDE boots slower on RedHat? (and no, I'm not running all the servers (sendmail, etc) that RedHat comes with).

Sometimes it's a bit confussing...


By Anonymous at Thu, 2002/07/18 - 5:00am

Geez, this ALWAYS happens. Someone makes a comment saying "My Konqueror takes X seconds to start up, and KMail takes Y!" Then someone else posts "Yours must be broken, mine only takes Z!" I think the problem is that everyone's configuration is different. So here's a new idea: Whenever someone posts a time for a KDE app to start, tell them to *move their .kde directory* and try it again. This will clear all KDE settings to their default values and allow some sort of accurate measurement. Without doing this, there can be no comparison of start times. And if it is discovered that a certain setting makes KDE apps start much much slower, then that can be found and fixed.

Like Waldo says, I really wish that GCC/Binutils would hurry up and get prelinking ready, and not because it would make KDE faster. It actually won't. KDE has already hacked around the problem with "kdeinit." While it will be nice to get rid of the kdeinit hack, the real benefit will be that people will no longer be able to blame the linker to hide KDE's *real* performance problems. Then maybe we will finally see some progress.


By not me at Thu, 2002/07/18 - 5:00am

> Like Waldo says, I really wish that GCC/Binutils would hurry up and get relinking ready, and not because it would make KDE faster. It actually won't. KDE has already hacked around the problem with "kdeinit."

Read his statement again. kdeinit links against common libraries used by KDE and thus can only help to speed up these. Not other libraries, the program's libraries or the program itself. This is where prelinking helps to improve speed.


By Anonymous at Fri, 2002/07/19 - 5:00am

Standard? Without distributor patches? Current libelf, binutils and Linux 2.4 have support. Only missing piece is glibc 2.3 which is said to be still released this year (perhaps RedHat exerts pressure on glibc maintainers because of RedHat 8.0).

But I heard the current approach to modify library headers is not very clever security-wise regarding checksums (you have to re-prelink a library if any library it depends on changes). So it perhaps has to be changed to store prelink information under /var instead.


By Anonymous at Fri, 2002/07/19 - 5:00am

What has been smoking. Here on my 2Ghz P4 with 1GB ram I am still having some performance issues and slow loading! Would it not be a better approach for developers to sort out fundamental performance issues before adding more features? Why not concentrate on bug fixes, performance enhancements and usability issues for the next few releases. There are more than enough features in KDE to keep ppl happy for the time being.


By Natra at Wed, 2002/07/17 - 5:00am

I swear, somewhere there is a script, generating these things...


By jd at Wed, 2002/07/17 - 5:00am

Maybe you have read the interview: one fundamental performance problem (delayed icon loading) is being addressed.
KDE runs usable on a K6/200 128 MB, and yes, 48 MB looks a little bit insufficient.

Bye
Alex


By aleXXX at Wed, 2002/07/17 - 5:00am

Not being a developer I wonder why 48 MB, which looks to be a lot, is not enough.
IMHO a desktop enviroment shouldn't take that much as it's just a framework where the apps run.
It's the apps which have to use the CPU and RAM.
I think that it's not the OS fault as I can run linux with little memory on my IPAQ and perfroms really well.
But I might be missing something.
Anyway I guess having a really polished enviroment is not very easy without paied developers.
It's REALLY A LOT what most of them are doing for free, so thanks guys!
Can anybody explain "in an easy way" why does KDE need so much memory?

Thanks


By Anonymous at Wed, 2002/07/17 - 5:00am

I share your oppinion. I had to upgrade to 512 Mb because KDE was eating too much of my original 256 Mb of ram causing massive swapping when I was working.

I do wish KDE would run lighter. Just starting konq eats 100% cpu time for 2-4 seconds on my 900MHz machine.


By heh! at Wed, 2002/07/17 - 5:00am

Hey, and i planned to buy a new computer soon. It seems my PII 233MHZ with 192MB
still outperforms all machines out there.


By Lenny at Wed, 2002/07/17 - 5:00am

KDE3 runs just *fine* on this computer. I just wish it would run even better.


By heh! at Wed, 2002/07/17 - 5:00am

That's just stupid. KDE runs fine in my 128M box.


By ac at Wed, 2002/07/17 - 5:00am

i have 256mg and i hardly ever swap.


By Echo6 at Thu, 2002/07/18 - 5:00am

One advantage of KDE is that the framework provides a lot of features to applications, so that application developers can focus on their application. The interest is that all KDE applications can benefit from these features, and that all these features (hidden in a small set of libraries: kdelib, ...) are loaded only once in memory, and then shared by all the KDE applications. This is why the memory is taken by KDE and not be an application.

These features include: standard dialogs (color chooser, file chooser, ...), component system, mimetype associations, inter applications communication (DCOP), XML gui, handling of global and local configuration file, transparent access to many file protocols, ...

Most of these features are generic. The interest is that they provide a very generic interface that can be used in many cases. They use C++ features such as template and virtual function to be generic. But this generic aspect creates more classes than you would require to implement just one particular case of this interface. The growing number of classes and virtual functions is what the linker has a problem with.

But the result is great. With KDE's file dialog, you can access local file system, ftp sites and http sites and many more. And you can preview your files, which uses two other mechanism (mimetype database and components). You can not do that with your IPAQ.

Be assured that stability, speed and memory consumption are watched very closely by developers and they do their best to reduce it.


By Philippe Fremy at Wed, 2002/07/17 - 5:00am

Will, in your oppinion, KDE apps boot fast with the problem of the linker solved?
Is really only a linker problem?
I mean how much of the start time can be reduced with an improved linker?
Will apps boot twice faster? Three times faster? Or 20% faster?
I'd really like to know what are we waiting for when we hear "Just wait until the linker is optimized and apps will boot faster".
Thanks.


By Anonymous at Wed, 2002/07/17 - 5:00am

KDE 2 konsole takes here 1.9 sec to start, linking is almost one second.

Bye
Alex


By aleXXX at Fri, 2002/07/19 - 5:00am

>IMHO a desktop enviroment shouldn't take that much as it's just a framework where the apps run.
> It's the apps which have to use the CPU and RAM.

If apps need the same functionality, it is a good idea to put this into a library shared by those apps.
This is what KDE does. It provides common functionality inside the KDE libraries.

If you watch an output of top, you'll see that most part of the memory consumption of a KDE app is shared with other processes.
So KDE apps have little memory overhead, common code is shared between them.

IMHO it is far better to have 20 MB used by KDE and only 5 MB overhead per app than to have 10 MB per app.

Cheers,
Kevin


By Kevin Krammer at Wed, 2002/07/17 - 5:00am

> Can anybody explain "in an easy way" why does KDE need so much memory?

It does an awful lot of things.

And memory usage reporting tools (top, free, ps...) are generally not reliable.

Anyway, RAM is cheap, just add some more and get over it, or run something lighter.

There's no Lost Art of Good Programming, no magic formula : features take ressources, period. We're not malloc-junkies or sloppy coders. There's always room for some optimisations, but nothing will make KDE fit into a ten year old machine.


By Guillaume Laurent at Wed, 2002/07/17 - 5:00am

"There's always room for some optimisations, but nothing will make KDE fit into a ten year old machine"

The problem is that even a 5 years old machine (pentium 133 with 16MB ?) is not enough. But on this machine, we were running Win95 with softwares like word95 or excel that were doing a good job (even if the os crashed a little bit too much).
What I do not understand is why do we need today to run 2Gig machine with 512MB to do the same work?? (and sometimes, it runs slower...).
I agree that nowadays machine are much better at handling big graphics and video but for normal office work...

Something else that I do not understand is why a simple application like the calculator take so long to start? Yeah, I know, the linker problem... but is there so many links to make on a so small application??

Sorry for the critics...


By Murphy at Wed, 2002/07/17 - 5:00am

Win 95 GUI is more comparable to KDE 1.1.2 than KDE 3.1. KDE 1.1.2 FLIES on such a machine ;-) Win XP does not run on 5-year old machines either.


By Anonymous at Wed, 2002/07/17 - 5:00am

Maybe KDE 1.1.2 flies on a pentium 133. But the new versions of koffice do not run on it...
and do the differencies between KDE 1.1.2 and 3.0.2 justify that I now need a such beast (2Gig, 512mb) to run office software ?


By murphy at Wed, 2002/07/17 - 5:00am

Someone has lied to you. You can run 3.0.2 in much less than a 2GHz, 512M machine. Hope this helps!


By ac at Wed, 2002/07/17 - 5:00am

Of course I know that, I am running it on a K6 550 with 256mb. What I mean is that with a such configuration, win98 is way faster than mandrake + kde (any version), even just to run office software.


By murphy at Wed, 2002/07/17 - 5:00am

Get an old version of StarOffice, or try apps like AbiWord, Gnumeric, etc.


By Carg at Thu, 2002/07/18 - 5:00am

> Win 95 GUI is more comparable to KDE 1.1.2 than KDE 3.1. KDE 1.1.2 FLIES on such a machine ;-)

Sorry, but I have to disagree. Win95 is still *a lot* faster than KDE 1 on my Pentium 166 (before I upgraded my CPU) with 48 MB RAM.
You don't want to try KDE 1 on a machine with only 16 MB RAM!

Win95 runs fine on 16 MB (but swaps a lot), but KDE 1 or GNOME 1.0 are INCREDIBLY slow on a system with 16 MB RAM. I believe it took 5 seconds to popup GNOME's main menu.


By Stof at Wed, 2002/07/17 - 5:00am

Win95 has very SIMPLE graphics subsystem, tightly integrated with the kernel, using all the abilities of hardware acceleration. I've run it pretty reliably on 8 MB system.
Linux has got X Window system with plenty of abilities ( network transparency and all that) that needs a lot of resources and is slow as hell on older hardware - just because of its abilities. Add the KDE overhead to that. We ran KDE1 on Pentium Pro 200 with 32 MB ram, and it was slow as hell - till we added more RAM, up to 128 MB.


By Alex at Thu, 2002/07/18 - 5:00am

example kcalc (still KDE2 at this machine):

neundorf@video:~$ ldd /opt/kde/bin/kcalc
kcalc.so => /opt/kde/lib/kcalc.so (0x40017000)
libkdeui.so.3 => /opt/kde/lib/libkdeui.so.3 (0x40041000)
libkdecore.so.3 => /opt/kde/lib/libkdecore.so.3 (0x40227000)
libkdefakes.so.3 => /opt/kde/lib/libkdefakes.so.3 (0x40355000)
libdl.so.2 => /lib/libdl.so.2 (0x40360000)
libDCOP.so.1 => /opt/kde/lib/libDCOP.so.1 (0x40364000)
libqt.so.2 => /usr/local/kylix2/bin/libqt.so.2 (0x40386000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x40a38000)
libz.so.1 => /usr/lib/libz.so.1 (0x40a62000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a71000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40a90000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40a9e000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40b77000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40b80000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40b97000)
libm.so.6 => /lib/libm.so.6 (0x40bdd000)
libc.so.6 => /lib/libc.so.6 (0x40bff000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

libc, libm, libstdc++, ld-linux.so, ok
libX11 and libXext since it is a X app
libkdecore, libkdeui, libqt well, it is a KDE app
libjpeg, libpng - it supports icons'n stuff
libdl - KDE supports plugins
libDCOP - dcop supprot
libICE - needed for dcop
libSM - session management
libkdefakes - portability fakes
libz - gzip compression, I think libpng requires this

So, not much room left to improve...

Alex


By aleXXX at Fri, 2002/07/19 - 5:00am

I'm not a developer, but win98 needs about 64mb & windows pro2000 need 128 so I think 48mb is a small amount required. It also depends what the OS maker wants to recommend. Microsoft says you can run win95 on 4mb ram (you can but you wouldn't want to)if they were serious they would recommend at least 32.Also as you add more features to an OS it requires more memory to hold the info in a temporary place. That is why DOS doesn't require alot of ram. I hope this helps.


By Jim at Wed, 2002/07/17 - 5:00am

DOS can't even USE more RAM.

"640k is enough for everybody" - Bill Gates.


By Stof at Wed, 2002/07/17 - 5:00am

On my old Pentium 233 with 48 MB RAM, KDE 2 runs fine. It just swaps too much after using it for a while.
But what I don't understand is why X + toolkit + desktop environment need so many memory (no I don't look at top's output, I use my feelings; my harddisk tells me that the system swaps *a lot*). Why is Win95 so fast? Win95 is an incredibly complex development platform.


By Stof at Wed, 2002/07/17 - 5:00am

If you didn't tell us anything about your (Linux) kernel, libs, distro, etc.
I think you are comparing apples and oranges.

Swapping is mostly a kernel (VM) issue.
Only the lastet 2.4.19rc1aa2 (soon 2.4.19rc2aa1) kernel has smooth VM behavior. Even in the corer cases. The -ac series comes close but with some distance.

-Dieter

PS Compile Qt, kdebase3, glibc and XFree86 your self and you can see it fly.


By Dieter Nützel at Thu, 2002/07/18 - 5:00am

You're kidding right... compile them on a Pentium 233?


By Stof at Thu, 2002/07/18 - 5:00am

I did it on a pentium 150 laptop with 32 Mb RAM :)
Actually I compiled all my system (Gentoo Rules!) on it :)

It took 5 days (mainly cause I had to recompile X 3 times... kernel sources ate all the HD space)

Now I use KMail on it when I'm away from my main machine. It takes like a minute + to start but then it works perfectly....

And it handles 9Mb of Mail quite decently :)


By Claudio Bandaloukas at Thu, 2002/07/18 - 5:00am

One minute swapping or linking?


By Anonymous at Thu, 2002/07/18 - 5:00am

Hey win95/8 on that machine will run faster.
New Gnome it's said it's lighter than 1.4
Try that one... This might be faster?

My brother is running Win2000 in a 266 with 96MB ram and works decently for email, Messenger, Explorer, and "joe user" stuff. Before the 64 MB upgrade I was running Win95 and it flied...
I had to buy a bigger machine to run KDE faster and gave my bro the "old" machine. And my bro still laughts at me when he sees konqui in my new machine loading slower :-P But anyway, I really like KDE and enjoy using it a lot.
I think I've spent more money on Hard than I would have saved on Licenses since I'm adicted to linux :-) It's strange but I think it's just a matter of community which sticks me to Linux/KDE

Good luck!


By 150 laptop? at Thu, 2002/07/18 - 5:00am

NO, that's why we have "cross platform compilation".

Regrads,
Dieter


By Dieter Nützel at Thu, 2002/07/18 - 5:00am

Hi Dieter and other developers,

>>PS Compile Qt, kdebase3, glibc and XFree86 your self and you can see it fly.

This is exactly the problem, only developers can do this. In order to profit from new introduced features and speedups, one has to use the latest versons of gcc, glibc, Xfree86, KDE and all programms/libraries that these programms depend upon. Upto now I have not seen a manual that explains me how to compile these programms from scratch (starting from p.e. SuSE 8.0).
So what I would like to see is something like

Install SuSE 8.0 with al least the following software installed:

Now download the following software:

Compile the software in this order
./configure

...

Other things that have to be done to have a nice KDE

...

The user-base of kde would be much larger and using
Linux/KDE would get a boost, since hungry users would no longer
have to wait for new distributions.

(I would still like to support distributions, but why has no distribution a European bank-account?)

I *really* hope this message will get some attention on kde-devel since I believe it's this that's holding people back. (Look at the increasing popularity of Gentoo)

Regards,

Richard Boom


By Richard Bollinger at Thu, 2002/07/18 - 5:00am

YES
I agree with you

KDE is not going to write basic system config tools as they told us to use distributions tools.
Ok. I like KDE and I'm going to use distributions as they told us.
Now, if KDE needs to be recompiled to get speed busts, explain how to do that, please.
I agree that I have to get a distribution, but then I don't have to use the distribution binaries if I want a speedy KDE?
Or, even better than that: "Please explain the distribution engineers how to compile KDE, as reading KDE developer posts, looks like distro engineers are doing a pretty bad job.
Thanks guys.


By Anonymous at Thu, 2002/07/18 - 5:00am

>> Upto now I have not seen a manual that explains me how to compile these programms from scratch (starting from p.e. SuSE 8.0).

Have a look at garnome.

http://www.gnome.org/~jdub/garnome/

It was originally made to automate download, compile and installation of gnome. You can do this with only a little more than a simple text file edit, a few 'cd's and about three 'make install's.

The maintainter (Jeff Waugh) added KDE 3.0.2 to it and you should be able to compile KDE with about this much ease all into its own directory.


By Jared Sulem at Fri, 2002/07/19 - 5:00am

> I *really* hope this message will get some attention on kde-devel since I believe it's this that's holding people back.

and i really hope it'll get some attention on XFree86-devel (or so), because X is a great source of problems for the Linux desktop:
- font handling is close to a plain joke
- simple tasks such as switching screen resolution (not zooming), are simply a nightmare (you have to reconfigure X: explain to the linux newbie to log under root, edit XF86Config, and stuff...)
- "advanced features" such as 3D or XVideo are poorly implemented (i have yet to find a graphic card for which it is correct: still not implemented for Mach64, crashing X regularly for Rage128/Radeon, proprietary for NVidia - and so, not very stable). btw KDE benefits of some of these features (antialias for instance), but nobody ever talk about graphic cards when complaining about KDE.

and moreover, X is so complex, that jumping in its development is harder than climbing on top of Everest. all that for what ? so-called "network transparency", that barely nobody needs, but induces a nightmare about not-breaking-compatibility-with-century-old-clients.
see what the guys from Apple did in MacOSX, simply after deciding to get rid of compatibility issues. (well, till Jaguar, their engine was slow, though).

i just hope it doesn't look too much like a troll ;-)


By loopkin at Mon, 2002/07/22 - 5:00am

How about this...

KDE runs extremely slow on my 2.4Ghz, 256MB Ram. When I switched to XFCE desktop environment, it runs EXTREMELY fast (as long as I have no KDE apps open, lol)


By wescott at Wed, 2005/03/30 - 6:00am

Pages