KDE 3.5 vs 4.0. Round two

摘自: www.jarzebski.pl  被阅读次数: 285


yangyi 于 2008-01-24 19:43:16 提供


One of my recent publications about the usage of memory by the upcoming KDE 4.0 and it’s comparison to the current KDE 3.5, emerged a heated discussion on the internet. First of all I want to clarify that the post title “KDE 3.5 vs KDE 4.0” should not be considered as a reliable and complete source of information about the subject. Precisely, due to the incompleteness of information presented by me, they were interpreted not the way I intended. The main reason behind this was presenting results based solely on the KSysguard application, which as it shows was somehow inaccurate (but not completely senseless).

This time, for conducting the tests I’ve used Exmap, which showed the results in a more reliable, accurate and detailed way.

Exmap – the facts

Example results of Exmap.


Exmap is an application that allows determining the exact physical and virtual memory usage by each of the running processes, showing the results in several specific cases such as :

  • Mapped size - the total of memory actually used by the process, both in RAM and swap. Note however that e.g. libraries are not swapped out to swap. This value includes even shared memory.
  • Resident size - similarly as the Mapped Size, but it’s specific only to the RAM (excluding swap).
  • Sole mapped - memory used only by this process. For example if a process uses a shared library that no other process uses at the moment it is included here.
  • Effective Mapped / Effective Resident - the effective values are an attempt to compute how much memory a process uses in practice. Effective mapped/resident are mapped/resident values adjusted for shared memory. Memory that is shared by more processes is equally divided among them, i.e. if 10 processes use a 10MB large shared library (and each of them really uses the whole library), the library is counted as 10MB in mapped/resident values but only as 1MB in effective values.

Test

To assure the credibility of the test, I’ve forced the kernel to work with noswap and mem=512 parameters. In other words, I hadn’t used the swap partitions and I’ve limited the memory to 512 MB. By not using the swap, I’m simplifying the operation by cutting of the measured values into a half (Values of Resident and Mapped will be identical).

The test was run on KDE 3.5.8 and KDE 4.0 rc2, trying to run identical applications such as (kmix, klipper, konsole, conqueror, kwrite, ksnapshot).

Tests on KDE 3.5.8


Tests on KDE 4.0 rc 2

Results

Exmap results : Resident size

KDE 4.0 (1) - With Composite, KDE 4.0 (2) - Without Composite.

Exmap results : Effective Resident size

KDE 4.0 (1) - With Composite, KDE 4.0 (2) - Without Composite.

Exmap results : Sole maped

KDE 4.0 (1) - With Composite, KDE 4.0 (2) - Without Composite.

Conclusion

The results obtained with Exmap significantly differ from the results obtained from KSysguard. By this I mean the memory used by particular processes. The first and the fundamental difference is that not every component of KDE 4 requires less memory. Some of them require it more like comparing Plasma to KDesktop or KWin.

Let’s check why:

KDE 3.5.8 - KDesktop


KDE 4.0 rc 2 - Plasma (with Composite)

And how it looks in Kwin:

KDE 3.5.8 - KWin


KDE 4.0 rc 2 - KWin (with Composite)

And XServer :

KDE 3.5.8 - XServer


KDE 4.0 rc 2 - XServer (with Composite)


As it could be expected, grater memory requirements are caused by using the Composite. We could expect that turning off the Composite will significantly decrease the memory usage. Nevertheless memory usage in KDE 4 is ls maller by 20%. But is it for real ?

The last two tables (Effective Resident, Sole Mapped), shows the facts: KDE 4 requires more memory. In similar conditions KDE 3 consumed 97 MB (+29 MB by XServer) on memory, whereas KDE 4 about 170 MB (+72 MB by XServer). But is it much more? Yes and no. The memory consumption is almost doubled, but the usage of new technologies and significant use of Composite, to achieve eye-friendly effects (which in fact could be turned off); we could justify the additional 110MB.

原文链接: http://www.jarzebski.pl/read/kde-3-5-vs-4-0-round-two.so