Slashdot Mirror
KDE 4 Uses 40% Less Memory Than 3 Despite Eye-Candy
An anonymous reader writes "Pro-Linux reports that KDE 4, scheduled to be released in January 2008, consumes almost 40% less memory than KDE 3.5, despite the fact that version 4 of the Free and Open Source desktop system includes a composited window manager and a revamped menu and applet interface. KDE developer Will Stephenson showcased KDE 4's 3D eye-candy on a 256Mb laptop with 1Ghz CPU and run-of-the-mill integrated graphics, pointing out that mini-optimizations haven't even yet been started." Update: 12/14 22:40 GMT by Z : Or, not so much. An anonymous reader writes "The author of the original KDE 3.5 vs KDE 4.0 memory comparison has come out with a more accurate benchmark. In reality, KDE 4.0 uses 110 MB more memory than KDE 3.5.8.
Someone call Bill Gates and tell him to read this.
Seek and ye shall find.
The laptop was recent, but he limited the memory use and throttled down the CPU to 1GHz. So it still had fancy instructions and a much bigger cache, bus, etc.
Tsunami -- You can't bring a good wave down!
The "unused" RAM won't be nice and empty. It'll be used as the system cache to store file data etc. that then can be accessed very quickly. Modern operating systems do not waste RAM by leaving it unused.
WAY too much bloat for features most never use. Real men use dash (if you *must* have a program that's a shell and only a shell) or if you don't mind something a bit more versatile to save disk space at potentially the risk of slightly higher memory consumption when all you have is a shell, you use a symlink to busybox for your shell. But not with that glibc cruft mind you, uClibc is the only path to efficiency.
Also, you don't use init, you have the kernel run the aforementioned shell directly instead. Who needs all the cruft of startup services and a well set up tty, after all.
XML is like violence. If it doesn't solve the problem, use more.
just to speed things up a bit:
"The fact that a new version of an application does not always ressourcenhungriger must prove the KDE project with the next generation of the environment."
I think I just found my new word-of-the-week
What!? Whatever happened to the "GUIs are for infants and grandmas. if you can't do it on the command line you shouldn't be allowed to use a computer in the first place" flame?
It's a sad day in Linuxland. What became of the holier than thou, I program in assembly, certifiable *nix prick?
Oh, and don't forget, "Desktop environment x is so bloated."
You young whippersnappers and your fancy shell this and tty that. Real men feed their programs into a time share systems as big as a barn using punch cards, you young hooligan! Why, when I was a lad, all we had were toggles and lights, and we were grateful! Now get off my lawn before I shake my cane at you a second time!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
I'd have to back you up there: when I first installed Ubuntu I went with KDE because it seemed less foreign than GNOME. (And I'm quite happy.)
The government can't save you.
I think this is probably true.
As a matter of corporate policy on a high level, Microsoft obviously benefits from and feeds into the upgrade treadmill. I don't think it's hard to believe that there's a quid pro quo with the hardware manufacturers on this; at the very least it's an obvious symbiosis. Microsoft craps out a new OS every few years with vastly increased system requirements (at least in order to run well), and in return the hardware manufacturers continue to bundle Windows. (There's more to the relationship, obviously, such as Microsoft's pricing structure for OEM licenses, but I think the hardware/software upgrade path is a part.)
However, I don't think most of Microsoft's programmers necessarily go into work every day saying to themselves "today, I'm going to build the shittiest, most resource-hogging chunk of code I can, so help me God." I suspect they probably just code for whatever their higher-ups tell them the target platform is going to be. If you're an overworked programmer, and if management makes it obvious that they care more about shoveling in the features than in optimizing code for performance and footprint, you're not going to optimize.
I think that's Windows in a nutshell. Somewhere along the line, some suit decides what the target platform is going to be; at the beginning of the development cycle it's probably pretty top-of-the-line kit. Everything is targeted towards this, and the end result is massive increases in bloat. Optimization is hard and unless you emphasize it and reward it, it's not just going to happen all by itself.
On the OSS side, you see a lot of optimization happen because many developers are working with limited resources and aren't in a position (or have the desire) to go out and buy a faster computer to make some chunk of code run faster. If you write an OSS application that requires your users to go out and buy a new system in order to use it, you've just alienated a lot of potential users -- or, hopefully, created a demand for someone to optimize the code and get it running on existing, slower hardware.
In short, I don't think Windows' footprint and mediocre (or negative) performance gains is due to bad coding as much as it's a direct result of institutional culture. It's a good example of what can happen to any product or project if performance isn't a key consideration, and particularly if it takes a back seat to featuritis.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Has no one pointed out that the numbers are actually completely, utterly wrong? See Lubos and Thiagos (two high-ranking KDE and Qt devs) comments here:
http://www.kdedevelopers.org/node/3138
See the original authors retraction, here:
http://www.jarzebski.pl/read/kde-3-5-vs-4-0-round-two.so
So really, it should be "KDE4 uses 75% more memory", which is actually incredibly lame, but doesn't make for as good a title. I'm absolutely amazed that usually cynical slashdot readers have accepted this so uncritically.
As with 99.9% of all memory benchmarking, it was done by someone who didn't totally understand how to measure memory use (and how Linux doesn't allow accurate measurements without a patched kernel). Just read the comments in the post which pointed at the original story.