OSnews: Interview with Waldo Bastian
Wednesday, 17 July 2002 | Dre
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:
You too can help KDE - send beer! - Eric Laffoon - 2002-07-17
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.
What I have liked the most: - Anonymous - 2002-07-17
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!!!
Re: What I have liked the most: - Matt - 2002-07-17
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.
Re: What I have liked the most: - Evan "JabberWokky" E. - 2002-07-17
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
Re: What I have liked the most: - Anonymous - 2002-07-17
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
Re: What I have liked the most: - Waldo Bastian - 2002-07-17
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
Re: What I have liked the most: - Anonymous - 2002-07-17
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.
Re: What I have liked the most: - Sad Eagle - 2002-07-17
Hmm, how was your Konqui compiled? I could produce times of about 1-1.5 seconds for optimized builds with my Celeron 950.
Re: What I have liked the most: - Anonymous - 2002-07-18
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...
Re: What I have liked the most: - not me - 2002-07-18
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.
Re: What I have liked the most: - Anonymous - 2002-07-19
> 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.
Re: What I have liked the most: - Anonymous - 2002-07-19
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.
KDE on a 166mhz PC with 48MB ram!!! - Natra - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - jd - 2002-07-17
I swear, somewhere there is a script, generating these things...
Re: KDE on a 166mhz PC with 48MB ram!!! - aleXXX - 2002-07-17
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
Re: KDE on a 166mhz PC with 48MB ram!!! - Anonymous - 2002-07-17
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
Re: KDE on a 166mhz PC with 48MB ram!!! - heh! - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Lenny - 2002-07-17
Hey, and i planned to buy a new computer soon. It seems my PII 233MHZ with 192MB still outperforms all machines out there.
Re: KDE on a 166mhz PC with 48MB ram!!! - heh! - 2002-07-17
KDE3 runs just *fine* on this computer. I just wish it would run even better.
Re: KDE on a 166mhz PC with 48MB ram!!! - ac - 2002-07-17
That's just stupid. KDE runs fine in my 128M box.
Re: KDE on a 166mhz PC with 48MB ram!!! - Echo6 - 2002-07-18
i have 256mg and i hardly ever swap.
Re: KDE on a 166mhz PC with 48MB ram!!! - Philippe Fremy - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Anonymous - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - aleXXX - 2002-07-19
KDE 2 konsole takes here 1.9 sec to start, linking is almost one second. Bye Alex
Re: KDE on a 166mhz PC with 48MB ram!!! - Kevin Krammer - 2002-07-17
>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
Re: KDE on a 166mhz PC with 48MB ram!!! - Guillaume Laurent - 2002-07-17
> 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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Murphy - 2002-07-17
"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...
Re: KDE on a 166mhz PC with 48MB ram!!! - Anonymous - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - murphy - 2002-07-17
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 ?
Re: KDE on a 166mhz PC with 48MB ram!!! - ac - 2002-07-17
Someone has lied to you. You can run 3.0.2 in much less than a 2GHz, 512M machine. Hope this helps!
Re: KDE on a 166mhz PC with 48MB ram!!! - murphy - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Carg - 2002-07-18
Get an old version of StarOffice, or try apps like AbiWord, Gnumeric, etc.
Re: KDE on a 166mhz PC with 48MB ram!!! - Stof - 2002-07-17
> 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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Alex - 2002-07-18
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - aleXXX - 2002-07-19
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
Re: KDE on a 166mhz PC with 48MB ram!!! - Jim - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Stof - 2002-07-17
DOS can't even USE more RAM. "640k is enough for everybody" - Bill Gates.
Re: KDE on a 166mhz PC with 48MB ram!!! - Stof - 2002-07-17
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Dieter Nützel - 2002-07-18
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - Stof - 2002-07-18
You're kidding right... compile them on a Pentium 233?
Re: KDE on a 166mhz PC with 48MB ram!!! - Claudio Bandaloukas - 2002-07-18
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 :)
Re: KDE on a 166mhz PC with 48MB ram!!! - Anonymous - 2002-07-18
One minute swapping or linking?
Re: KDE on a 166mhz PC with 48MB ram!!! - 150 laptop? - 2002-07-18
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!
Re: KDE on a 166mhz PC with 48MB ram!!! - Dieter Nützel - 2002-07-18
NO, that's why we have "cross platform compilation". Regrads, Dieter
Re: KDE on a 166mhz PC with 48MB ram!!! - Richard - 2002-07-18
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: <list> Now download the following software: <list> Compile the software in this order <list> ./configure <options> ... Other things that have to be done to have a nice KDE <for nice fonts see www...> ... 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. <Off-topic> (I would still like to support distributions, but why has no distribution a European bank-account?) </off-topic> 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
Re: KDE on a 166mhz PC with 48MB ram!!! - Anonymous - 2002-07-18
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.
Re: KDE on a 166mhz PC with 48MB ram!!! - aleXXX - 2002-07-19
Visit these pages: http://developer.kde.org/source/anoncvs.html http://developer.kde.org/build/compile_cvs.html Alex
Re: KDE on a 166mhz PC with 48MB ram!!! - Jared Sulem - 2002-07-19
>> 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.
Re: KDE on a 166mhz PC with 48MB ram!!! - loopkin - 2002-07-22
> 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 ;-)
Re: KDE on a 166mhz PC with 48MB ram!!! - wescott - 2005-03-30
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)
Re: KDE on a 166mhz PC with 48MB ram!!! - Benoît Minisini - 2002-07-18
Here are my own point of view on "Why Linux+X+KDE is slower than Windows on the same machine ?" 1) First, it is not the fault of Linux. Every test I have seen gives the Linux kernel faster than any version of Windows and Windows NT on equivalent functions. 2) Windows is faster in graphics drawing, because it is integrated in its kernel, and because its drivers are made by the constructors, so there are highly optimized. 3) Windows is faster in graphics drawing, because graphics seems to have a higher priority than the other system tasks. (It is a psychological choice). But maybe I'm wrong on this point (X-Windows has a higher priority too). 4) X-Window is slower, because when you send it a primitive, it is marshalled, sent to a socket, unmarshalled, and then managed by the X server. It is many times slower than making a system call ! Especially when you just want drawing a line or a rectangle... 5) X-Window is slower, because its drivers are sometimes, on some functions, not optimized. 6) X-Window is slower, because when you want to deal with a bitmap, you must download it from the X-server to your program, process it, and then upload it to the X-server. When the bitmap is huge, the unnecessary data copy is a bottleneck. With the X-SHM extension, this process is a bit quicker, but stays not optimal. 7) Graphics application under Linux may be slower, because of not using the special instructions of x86 processors (MMX, SSE, etc.). They can't because they must be compiled on other processors than the x86 ones. 8) Linux is slower in launching programs because of the well-known dynamic library loader in glibc. This problem should be adressed with GCC 3.1. I hope so ! 9) Windows is faster in lauching programs because of many internal optimizations : - Dynamic libraries are preloaded. - Many dynamic libraries are preloaded at the same address for every process that use them. - Programs like Explorer or Office are preloaded (it is a psychological optimization !) These optimizations are possible because, under Windows, 90% of the executed code comes from Micro$oft, and because dynamic libraries of Windows have less functionalities than the ELF format used under Linux. It is not possible to do the same thing in a free OS like Linux. Maybe you could do these optimizations with glibc, which is used everywhere. But you couldn't go as far as Microsoft did. The KDE guys did their best with kdeinit. With GCC 3.1, the things will be better. But I think the major bottleneck resides in X-Window. I'm optimistic. I think graphics under Linux will be faster than Windows in a few years, with a transformed X-Window, or an alternative. Be patient ! Freedom is more important than speed...
Re: KDE on a 166mhz PC with 48MB ram!!! - me - 2002-07-18
I already forgot about the gcc 3.1 sutff because, as Waldo said, this has been mostly solved by kdeinit. After all, gcc people don't have the fault of KDE loading slow. A lot of people should apologise to gcc people I think. I hope we don't blame now X if it's not their fault!
Re: KDE on a 166mhz PC with 48MB ram!!! - Stof - 2002-07-18
> Windows is faster in graphics drawing, because it is integrated in its kernel, In kernel space doesn't automatically mean faster! > Windows is faster in graphics drawing, because graphics seems to have a higher > priority than the other system tasks. So renice -15 `pidof X` will make everything faster? I've hardly noticed any improvement in performance. And except when drawing big animations, X uses very little to almost no CPU power. > 4) X-Window is slower, because when you send it a primitive, it is > marshalled, sent to a socket, unmarshalled, and then managed by the X server. Most of the data (pixmaps) are locally transferred using shared memory. > 7) Graphics application under Linux may be slower, because of not using the > special instructions of x86 processors (MMX, SSE, etc.). All the Linux video players I've seen (Mplayer, Xine, etc.) have *heavily* optimized using assembly. Even Gdk-Pixbuf contains MMX code. And how much difference does it really make if MMX/SSE/3Dnow is used in drawing static graphics? Windows are only drawn once every expose, and CPUs these days are 2+ Ghz. > They can't because they must be compiled on other processors than the x86 > ones. All you have to do is #ifdef PENTIUM_MMX // optimized assembly code #else // portable C/C++ code #endif
Re: KDE on a 166mhz PC with 48MB ram!!! - Benoît Minisini - 2002-07-18
> > Windows is faster in graphics drawing, because it is integrated in its kernel, > > In kernel space doesn't automatically mean faster! No, but it helps a lot... > > > > Windows is faster in graphics drawing, because graphics seems to have a higher > > priority than the other system tasks. > > So renice -15 `pidof X` will make everything faster? I've hardly noticed any improvement in performance. And except when drawing big animations, X uses very little to almost no CPU power. On my PII-400, X has a -10 priority. Moving the mouse takes about 2.5% of CPU Moving a window with contents easily takes 30% of CPU Graphics advantage is evident under Windows. Under Windows NT, I do not know if graphics are managed by a special kernel thread, or something equivalent. > > > > 4) X-Window is slower, because when you send it a primitive, it is > > marshalled, sent to a socket, unmarshalled, and then managed by the X server. > > Most of the data (pixmaps) are locally transferred using shared memory. Yes, but primitives does not use shared memory. When a window must be redraw, it send a lot of line, rectangle, pixmap, font drawings. I think if the primitive stream sent each time a window is redraw was cached by the X-server, drawing speed with X could greatly improve. > > > > 7) Graphics application under Linux may be slower, because of not using the > > special instructions of x86 processors (MMX, SSE, etc.). > > All the Linux video players I've seen (Mplayer, Xine, etc.) have *heavily* optimized using assembly. Even Gdk-Pixbuf contains MMX code. > And how much difference does it really make if MMX/SSE/3Dnow is used in drawing static graphics? Windows are only drawn once every expose, and CPUs these days are 2+ Ghz. > You are completely right. I didn't say that -no- application use MMX/SSE/3Dnow. For example, reading a DivX ;-) movie with mplayer under Linux is faster than reading the same DivX under Windows XP, even if you use the -same- codec (on my PII-400). > > > They can't because they must be compiled on other processors than the x86 > > ones. > > All you have to do is > #ifdef PENTIUM_MMX > // optimized assembly code > #else > // portable C/C++ code > #endif Yes. If you have time... And this kind of optimizations is mainly needed in video codecs, image effects and sound effects. Using them under other free software seems to be recent. Maybe under a fast machine (like I do not have), the bottleneck is more in disk access and library loadings, and on slow machines it is in graphics drawing.
Re: KDE on a 166mhz PC with 48MB ram!!! - Murphy - 2002-07-19
But the slowness of kde is not only in the graphics and in the loading of applications. Try suppressing 1000 files in a directory or move 1000 files from a directory to another, under windows or in a shell under linux, it is going fast (time measures in second). Under Konqi, it needs several 10 minutes, especially to move the files. You will tell me that we do not move 1000 files every day. But I do.
Re: KDE on a 166mhz PC with 48MB ram!!! - Asokan - 2002-07-19
I am really disturbed by all these talks. I use KDE and love using it, the brilliance it adds to the functionality, the integrated file and web browsing... I have a PIII 667MHz with 64 MB RAM, and KDE has been working well on this machine. Applications take some time to load, but once loaded they are fast. Will I get a similar performance with KDE3 which I am going to upgrade to, or is KDE3 significantly slower than KDE2. But sure, from my experience with many desktops I have used I can tell KDE is simply the best. Windows Desktop and the whole OS are only toys compared to KDE/Linux
Re: KDE on a 166mhz PC with 48MB ram!!! - Stuart Herring - 2002-07-20
> Moving the mouse takes about 2.5% of CPU > Moving a window with contents easily takes 30% of CPU I really hate it when people talk about how much CPU% a process takes up. Any running process, no matter how simple, will take up 100% of CPU time for the duration it is running. plain CPU usage is one of the most pointless measurements there is. _Average_ CPU usage over X seconds where X is actually mentioned along with the CPU usage does mean something, but a CPU usage number on it's own means nothing.
Re: KDE on a 166mhz PC with 48MB ram!!! - Sad Eagle - 2002-07-19
> All you have to do is > #ifdef PENTIUM_MMX > // optimized assembly code > #else > // portable C/C++ code > #endif And this code will not get used by most people, since none of the common binary distros requires a MMX-capable CPU on IA-32 targets. The right way to do this is with CPUID and runtime testing.
KDE Trash - Alex Ivarsson - 2002-07-17
A small question. Is it possible to put the trash-icon in KDE onto the panel and then use it from there with all the functionality? Even in real life, I prefer not putting the trash onto my desk.
Re: KDE Trash - Anonymous - 2002-07-17
LOL. Funny off-topic :-) Just drag and drop it from desktop to kicker. It looks to work on my system
Re: KDE Trash - me - 2002-07-18
hehe... good one :o)
Tounge-in-cheek - Johnny Andersson - 2002-07-19
What exactly does tounge-in-cheek mean?
Re: Tounge-in-cheek - garyK - 2002-07-19
Johnny, http://www.dictionary.com/search?q=tongue-in-cheek It means jokingly or not seriously. Cheers, GK
Re: Tounge-in-cheek - Johnny Andersson - 2002-07-20
Thanks! I even managed to spell it wrong. ;)
Re: Tounge-in-cheek - What does it mean> - 2002-10-16
help
Re: Tounge-in-cheek - Helper - 2005-08-20
What kind of help do you need: a) physical b) mental c) emotional d) all of the above
Re: Tounge-in-cheek - Mafferz - 2008-01-19
It's just something that bloody idiots that can't spell say when they're quipping.