Re: Memory Usage - KDE - Where is discussion on this?
As has been mentioned before, the trade-off between memory usage, speed,
and fuctionality is left to the individual. KDE3.1 gives an enormous amount
of functionality, hence it uses quite a bit more memory and can be slower
on systems that are limited by this.
Gnome is in a similar situation. The difference I find, now that I'm
building my own KDE desktop, is KDE uses qt libs and kde libs. Gnome, on
the other hand, uses upto 30 different library packages before you can even
start building the desktop. Of course these are smaller and probably
together come close to the qt/kdelibs size. It just that if you are
compiling them yourself, it's easier to compile two large libs that 30
small ones ;-)
In comparision, fluxbox needs nothing outside of xlibs to build and run,
but it's a very spartan desktop. XFCE uses gtk and glib, in addition to the
general imaging libs, but not the rest of what Gnome needs. I've used CDE
boxes before, so I kinda like XFCE. Either of these desktop run circles
around most other desktops available, I.E. M$XP/ Mac OSX and have much less
memory requirements.
As a Debian user, it's quite easy to install these other desktops or other
window managers to see what suits you. If your memory is limited, fluxbox
can detect and run both KDE and Gnome tools correctly. XFCE has it's own
drag-N-drop capability that is quite handy, once you get your head around
the new way of thinking. The big advantage in the Linux area is the freedom
to choose which desktop suits your needs and system limitations. M$ and Mac
don't give you that choice.
Of course the subject of possible memory leaks is a completely different
area. If you find that memory is getting used up and not freed on the
system after extended use, this certainly needs to be explored and brought
to the attention of the correct people.
As Debian only provides compiled packages of other peoples software, these
issues need to be taken up stream. The difficulty is figuring out where the
memory leak is and proving it. X has been accused of memory leaks in the
past, but the X team seem very diligent in testing for this, and they know
a lot about how memory is used in a running system, so that is not a likely
candidate. This gives you qtlibs and the KDE suite. Tying down just where a
memory leak may be between these would take a lot of effort and time. If
you've spare boxes with time to run various setups for extended periods to
watch for such leaks, I'm sure there are a few tips on tracking just what
program or library might be the culprit. Good accurate bug reports that
detail where the memory leak is and how you identified it would probably be
most welcome to the KDE and QT teams.
Cheers,
John Gay
Reply to: