Announcement

Collapse
No announcement yet.

Power & Memory Usage Of GNOME, KDE, LXDE & Xfce

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Well, what distro did you want him to use for the test? Most people don't install a vanilla distro and then add their desktop? They choose their fav. distro and pick the version they prefer (many distros have a DE version). I guess if you are talkin about Gentoo????

    KDE 4 is said to be a resource hog now. I think it's tough to assess because both desktops use the library of the other for certain applications. Or am I wrong there?

    I liked this article and test because I was curious about the DE since I was wondering what DE to use for my older laptop. I currently have AntiX and Debian Squeeze with LXDE on it. I like LXDE but a few minor annoyances I had was that it didn't seem to have many native apps so I picked and chose ones I already like (but, it then had to add the libs from either Gtk or Qt depending on the app). I am not sure how well that works and how well the lighter desktops integrate. Anybody know?

    I'm a total noob regarding this stuff so if I sound silly on any of it, that's why but at least I admit it, right?

    Comment


    • #17
      don't forget that KDE also provides a lot more features out of the box. Or does XFCE or gnome have nepomuk enabled?

      And what happens if you start a couple of apps? Firefox for gnome/xfce, konqueror for KDE? Abiword for gnome, kword for KDE?

      And if that test program was gtk based, the results are skewed and crap anyway.

      Comment


      • #18
        Seriously flawed

        The methodology used to conduct these "benchmarks" is *seriously* flawed.

        1. You were NOT benchmarking GNOME vs. KDE vs. LXDE vs. Xfce as such, but rather their *buntu incarnations.

        2. The last time I tested Kubuntu, KDE had a horrible memory usage there because of some crap applications running in the background.

        3. When I restart my computer into KDE 4.4.1, my memory usage is approximately 190MB used by applications (that does not include cache of course).

        4. Instead of forcing me and everybody else to read the totally cryptic paragraph describing the system&OS configuration, why not simply put those specs into a nice and readable table!!!

        5. The sad truth is that many desktop applications are using too much memory these days. For example, KCalc in KDE 4.4.1 uses 3 MB of private memory (not including shared memory). Now tell me what those 3 mega-bytes could possibly contain in such a trivial calculator application! I understand what that memory is being used for, but in my opinion the facts are horrible and speak of inefficiency.

        6. KDE uses Qt. The memory usage of KDE may be mainly caused by the fact that it uses Qt. So, first it is Qt to be blamed, only then blame KDE. A trivial graphical "Hello world" in Qt4 uses more than 2 MB of private memory. Am I alone in thinking that this is clearly a sign of a completely wrong software architecture?

        Comment


        • #19
          yes, you are alone. Qt isn't very memory hungry.

          But that does not change the fact, that the whole thing is complete bull.

          Comment


          • #20
            Originally posted by energyman View Post
            yes, you are alone. Qt isn't very memory hungry
            Seems you have different standards than me.

            But let me ask you a question: Have you ever looked into the source code of some Linux executable or library? I have, and from what I have seen I can tell you that the amount of inefficiency in common Linux programs is breathtaking. Seriously, if you think about the algorithms used there and compare them to "ideal" implementations, the result is shocking. The number of totally pointlessly burned CPU cycles is massive.

            Comment


            • #21
              Now let's say you wanted to use an app that needs most of your memory, like GTA IV if it was ported, you will run out, which is ridiculous and wrong for DE to waste that much memory. No my memory is not cheap, I'm still using old Windond BH-5 modules that run at 2-2-2-0 @ 3.45v, you can't upgrade that or put more sticks since chipset will not handle it and become unstable. In my book DE the max for i386 should be at most 100MB, and for x86_64 150MB. Maybe that's the reason why I still use XP. Win32 FTW!

              I would see the compromise for using that much memory if those shitty DE gave the responsiveness of what Windows gives. Not even Nvidia drivers help or tweaked SSD disk with unregressed file systems. What sucks even more is that KDE is dead slow and sucks ass. Starting a text editor or calculator takes a 1.5s delay? To do what? WTF?

              Comment


              • #22
                Originally posted by << ⚛ >> View Post
                Seems you have different standards than me.

                But let me ask you a question: Have you ever looked into the source code of some Linux executable or library? I have, and from what I have seen I can tell you that the amount of inefficiency in common Linux programs is breathtaking. Seriously, if you think about the algorithms used there and compare them to "ideal" implementations, the result is shocking. The number of totally pointlessly burned CPU cycles is massive.
                Got any links, or any example programs to look at?
                Quite often what may seem to be inefficient is actually efficient at runtime, or is done a certain way for a reason, or contains an awful lot of error handling.
                Certainly this isn't always the case, and a good many tools have been rewritten, but just bear it in mind when looking through things.

                Comment


                • #23
                  @<< ⚛ >>

                  Patches welcome, no? If you have the time to test how an ideal ls performs, you've already done the work.

                  Comment


                  • #24
                    Funny, Phoronix released this bench just after I posted this query for a bench..

                    OK, KDE uses more memory than other DEs. Don't know what to think about it. Even if these were run on *buntu systems, where Kubuntu is not known to be the best KDE, I think there must be an explanation to be given for the gaps show for battery consumption and temperature, which is very important. Memory usage ... well it also depends on the way the DE itself works and its conception (shared memory, etc.).

                    But at least it may lead to my initial query.
                    I haven't found a way to contact Phoronix to submit this new subject for a bench article.

                    Comment


                    • #25
                      On my system with KDE installed, it is using about 190MB of RAM when I load to the desktop. On a virtual machine, which also has KDE installed, I measured it using 150MB of RAM at the desktop. This was with Konsole running. I run a lightweight KDE desktop on my Gentoo Linux machines with things like background indexing off. I suspect that the Ubuntu test machine did not have this sort of option. It would be nice to see these same tests done with such features off.

                      Comment


                      • #26
                        Originally posted by mirv View Post
                        Got any links, or any example programs to look at?
                        Speaking of Qt 4.6.2, you can try this test-case: Create a trivial GUI application and all it does is to paint a rectangle with a size of the whole window. Print to the console the time it takes to paint the rectangle. Maximize the window to full-screen. Use Alt+Tab to force a repaint.

                        Now, execute it like this to use the raster engine:

                        1: ./test -graphicssystem raster

                        2: QT_NO_MMX=1 QT_NO_MMXEXT=1 QT_NO_SSE=1 QT_NO_SSE2=1 ./test -graphicssystem raster

                        I have notebook with an Intel CPU which supports MMX/SSE2. So Qt will use a MMX/SSE2-based routine in case 1.

                        Now take a guess: Which is faster? 1 or 2?

                        Well, on my notebook, disabling MMX/SSE results in faster drawing of the rectangle (by 30%). You might think, Qt has support for those fancy MMX/SSE2 instructions, so you think you are safe because Qt will automatically use the implementation most appropriate for your CPU - well guess what, you are not safe because the supposedly better version is actually slower!!!

                        (That was on my notebook CPU, other CPU's may behave differently).

                        Originally posted by mirv View Post
                        Quite often what may seem to be inefficient is actually efficient at runtime, or is done a certain way for a reason, or contains an awful lot of error handling. Certainly this isn't always the case, and a good many tools have been rewritten, but just bear it in mind when looking through things.
                        I was talking about actual usage. It wasn't "theoretical".

                        Comment


                        • #27
                          Originally posted by curaga View Post
                          Patches welcome, no? If you have the time to test how an ideal ls performs, you've already done the work.
                          1. It is not as simple as it sounds. The time required to actually implement a patch may be much longer than the time to pinpoint what the bottleneck is.

                          2. Last week, I submitted a patch for BASH 4.1. Maybe the maintainer will include it into BASH, or not, I don't know. In case BASH is parsing a lot of scripts, the patch makes it faster by 25% or something. I think, further performance improvements to BASH are certainly possible, but I find it unlikely that I will submit more patches. I don't like BASH in general, I don't like its implementation, and I don't like to program in C. (He, that was a nice sentence.)

                          I don't know what you think about "the state of Linux applications", but I am somewhat disappointed. But on the other hand, I am not disputing that many of them are working "just fine".

                          Comment


                          • #28
                            Well, great many people come here to complain about vanilla sources, etc. They just can't understand that these tests are not for them.

                            Point is: it doesn't matter if you can tweak an app to use half the ram of the default one or run 3x faster if you need to compile it from source and read about the optimizations for long hours. I dare to say that >90% of linux users won't care about that, just pick the one which is better with its defaults.

                            Originally posted by energyman View Post
                            And if that test program was gtk based, the results are skewed and crap anyway.
                            If I understood correctly the tests were started from terminal, so I assume no gui was started. Consequently, I think no additional gtk libraries were loaded, so your statement is not true.
                            I might be wrong here, I'm not familiar with pts...

                            Comment


                            • #29
                              Great comparison Michael. I think Lubuntu is going to be a great lightweight distro. Also it's good to know that GNOME devs actually understand that memory is a shared resource. Unlike the fglrx and KDE devs who either think they can take it all, or that memory is an infinite resource.

                              Comment


                              • #30
                                Heh, on my laptop with KDE 4.3 the battery gets about an extra half hour of life from a charge compared to Gnome (with compiz).

                                Comment

                                Working...
                                X