That's a good point, but a good comparison chart may be useful to make decisions for embedded systems or other special cases.If I don't like the way something works, I don't care how many or how few resources it uses.
It is the lightest that consumes few machine resources.What is the x-axis in this graph? Is it MB? RAM or disk space?
Does Gnome 3 include Mutter and KDE include KWin or are they separate?
The article clearly states it RAM used, no metrics about resources.It is the lightest that consumes few machine resources.
Well, you need to run a test with switching between windows and workspaces etc. Maybe using x11/xdotool.Perhaps for some kind of average on a PC without running other graphical applications for a minute?
ps ax | grep [mywm]
. Then, I run top -p [pid# of wm]
. ls -l /usr/local/bin/jwm
gives 224,984. top
?I believe, most of those charts are rather speculations.Rephrased, how would I get the number that was used in the chart for memory? Is it RES fromtop
?
It has to be something more than that. RES makes the most sense of what I can see, but I'm not sure.I believe, most of those charts are rather speculations.
That's besides the point.Since the memory is not a problem in most desktop PCs, I don't mind if a WM takes, e.g. 200MB, but doesn't continuously consume CPU cycles.
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
1382 amy 3 20 0 48M 25M kqread 7 0:01 0.00% i3
1414 amy 3 21 0 50M 26M CPU2 2 0:20 3.94% i3bar
1425 amy 1 52 0 11M 2356K kqread 7 0:01 0.28% i3blocks
BeagleBone Black has only 512MB of RAM. Would you suggest anything better for a real task performed in the full industrial temperature range -40°C... 85°C?Someone mention embedded systems, even those have now a lot of internal storage and ram memory
That chart is old and irrelevant.
The methodology of the chart is highly dubious too. "KDE" and "KWin" as separate entries? How do you measure the RAM usage of an entire desktop environment? Sure, a window manager alone is easy enough, but I'm fairly certain the GNOME window manager is not using that much RAM; when measuring an entire DE, are you counting just its running programs, or looking at the system-wide used RAM at a point in time?That chart is old and irrelevant.
That Gnome is a DE and not a window manager the chart shows that it, without the WM, is resource intensive. It's inaccurate, but it shows that Gnome as a DE adds a lot to what the WM is.How do you measure the RAM usage of an entire desktop environment?
Gnome has used different window managers. It has used Enlightenment, and PekWM. I'm unsure of which it uses now.Sure, a window manager alone is easy enough, but I'm fairly certain the GNOME window manager is not using that much RAM; when measuring an entire DE, are you counting just its running programs, or looking at the system-wide used RAM at a point in time?
It lacks, because it doesn't say what exactly it's measuring as of RAM. The chart still has use, because it shows a comparison of what it's measuring, to give an idea of resource intensiveness by WM. It's likely measuring RES (Residential Memory), but we don't know for certain.It's both old and doesn't convey any useful information, at all.
… the source of information, I believe, it's this article (although is pretty old). …
Actually I do, and they are designed for industrial applications, not like BBB which is for amateurs/hobbyists, just like RaspberyPi. See more here.BeagleBone Black has only 512MB of RAM. Would you suggest anything better for a real task performed in the full industrial temperature range -40°C... 85°C?
Kwin can be runned as standalone."KDE" and "KWin" as separate entries?
Gnome 1.x used Sawfish (Sawmill) as a window manager. The part from Enlightenment it used was the enlightened sound daemon (now PulseAudio), which was made obsolete by ALSA and OSS4. Gnome 2.x switched to Metacity and Gnome 3.x to Mutter. Pfew, I'm getting old.Gnome has used different window managers. It has used Enlightenment, and PekWM. I'm unsure of which it uses now.
Well, it's hard to compare. E.g. imx8m has only 8 GPIOs, wheras the BBB has 69! The same with SPI/I2C: just one port of each? Come on, for real industrial applications it's not enough.they are designed for industrial applications, not like BBB which is for amateurs/hobbyists
… Would the memory in the chart be RES? … fromtop
?
41 MB
of something in the 2013 article. M_RESIDENT (RES)
The resident set size (text + data + stack) of the process (i.e.
the size of the process's used physical memory).
70 M
RES in a memory-constrained environment. A shot from before the drop to sixty-something: <https://forums.FreeBSD.org/threads/freebsd-screen-shots.8877/post-529480>top(1) says:M_RESIDENT (RES) The resident set size (text + data + stack) of the process (i.e. the size of the process's used physical memory).
What top and htop state for RES seem to be different.SIZE is the total size of the process (text, data, and stack),
RES is the current amount of resident memory
What to read, all the conjectures and juggling that some users put in order to justify the mediocrity and the immense consumption of resources of the machine in vanilla system of some systems with graphical desktop environments, without accepting the benefits offered by most window managers such as TinyWM, which thanks the machine a light ultra fast system in vanilla system to start. Already in use of the system with how many windows or browser tabs open as firefox, which does not even reach 500Mb of memory or excess consumption of the cores that reaches 10 to 15%. Of course, as they have KDE Plasma, windows or Gnome everything justifies the excess consumption of the resources of the machine.Maybe.
KWin eight years ago was almost unknown to me.41 MB
of something in the 2013 article.
From the manual page for htop(1):
Code:M_RESIDENT (RES) The resident set size (text + data + stack) of the process (i.e. the size of the process's used physical memory).
Today I got a measurement of less than70 M
RES in a memory-constrained environment. A shot from before the drop to sixty-something: <https://forums.FreeBSD.org/threads/freebsd-screen-shots.8877/post-529480>
FreeBSD bug 258170 – The manual page for htop(1) is missing from the web site
teo: if you feel battered, please don't. The chart was old and vague, but thought-provoking