TinyWM the lightest of all window managers and desktop environments.

TinyWM is the lightest of all window managers and graphical desktop environments.
 

Attachments

  • screen.png
    screen.png
    64.1 KB · Views: 3,494
First of all, it's good to know the source of information, I believe, it's this article (although is pretty old).

Secondly, I wouldn't name "lightest" the one with the least memory footprint.
Really, who cares if the RAM used is 0.2MB (TinyWM) or 1MB (DWM) when you have a few gigabytes available? Maybe one of those "light" WMs runs, e.g. tight loops and consumes significantly more CPU resources. Not a fair comparison.
 
If I don't like the way something works, I don't care how many or how few resources it uses.
That's a good point, but a good comparison chart may be useful to make decisions for embedded systems or other special cases.
The chart in the OP won't work for such purpose: they chose a parameter which is easy to measure, but it's useless in the context of the "lightness".
 
We need a newer graph. Also, a lot of dependencies were added to some since that graph, that make it work with more gtk and other toolkit related programs, since then. That will give it a different statistic on the graph, than how it is at minimum, or how it originally was.

I would like to see a graph that adds: CTWM, CWM, MCWM, AntiWM and VTWM. It would be interesting to see how these compare to TinyWM and TWM. Ones on that list that would be nice to compare based on current metrics: JWM, Blackbox, FVWM, i3, Fluxbox and a few others.

MCWM was inspired by TinyWM, EvilWM and CTWM. It requires a terminal console, so it's started differently than other window managers. I wouldn't be surprised if it uses less resources than TinyWM, because of how it's written directly on top of XCB, and most control is limited to the terminal emulator.


What's the best way to get metrics for window managers? I can use top. Perhaps for some kind of average [RAM or CPU metric] on a PC without running other graphical [desktop] applications for a minute? Perhaps for RAM and CPU?
 
When I run JWM, as an example only, I find the PID with ps ax | grep [mywm]. Then, I run top -p [pid# of wm].

SIZE gives a number of 44M, and RES gives 5528K, (and sometimes a lower number around 5,300K, to a higher number of 5,700K). Would the memory in the chart be RES? To be sure that SIZE isn't the size of the program, ls -l /usr/local/bin/jwm gives 224,984.

I also believe if I compiled JWM without the dependencies added for X11 desktop applications, the RES would be closer to 3MB. To unset them, I can't do many of them through options. I would have to hard-set it.


Rephrased, how would I get the number that was used in the chart for memory? Is it RES from top?
 
Rephrased, how would I get the number that was used in the chart for memory? Is it RES from top?
I believe, most of those charts are rather speculations.
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. It could be a very responsive and lightweight WM.
 
Here is my DWM with exactly the same configuration and compiled manually with Clang:
1. FreeBSD 13.0, dekstop with 2 monitors (xinerama): RES = 2.7MB
2. Devuan 4, laptop with a single display: RES = 6.3MB
 
That chart is old and irrelevant. Someone mention embedded systems, even those have now a lot of internal storage and ram memory.
e.g.
i3-gaps+i3bar+i3blocks on FreeBSD 12.2:

Less:
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

As you can see my WM&Co. take 109MB to run. Do I care about 109MB when the machine has 16GB ram? Even running KDE and I'd be OK for a desktop/workstation/home computer.
 
Someone mention embedded systems, even those have now a lot of internal storage and ram memory
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?
 
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?

It's both old and doesn't convey any useful information, at all.
 
How do you measure the RAM usage of an entire desktop environment?
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.
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?
Gnome has used different window managers. It has used Enlightenment, and PekWM. I'm unsure of which it uses now.
It's both old and doesn't convey any useful information, at all.
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.
 
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?
Actually I do, and they are designed for industrial applications, not like BBB which is for amateurs/hobbyists, just like RaspberyPi. See more here.


"KDE" and "KWin" as separate entries?
Kwin can be runned as standalone.
Gnome has used different window managers. It has used Enlightenment, and PekWM. I'm unsure of which it uses now.
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.:)
 
they are designed for industrial applications, not like BBB which is for amateurs/hobbyists
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.
 
… Would the memory in the chart be RES? … from top?

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 than 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>

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 :)
 
M_RESIDENT (RES) The resident set size (text + data + stack) of the process (i.e. the size of the process's used physical memory).
top(1) says:
SIZE is the total size of the process (text, data, and stack),
RES is the current amount of resident memory
What top and htop state for RES seem to be different.


From what I'm learning, is that JWM uses different amounts of RES depending on what it's compiled with (, but didn't before). It's odd that, before, when everything was compiled with it, RES was on the low side of 4MB to 5MB. After recompiling it with no dependency options, it was 4-5M. With a few dependency options, it was 10M. Other options increased it to 15MB, and all options increased RES to 25MB. I'm not sure why before, all options compiled with it, its RES was about 4 to 5MB. It could be that programs that need those dependencies were previously started before the window manager started from .xsession.


Is there a better metric to use than RES (Resident Memory), or a better measurement related to RES? and of which program?
RES is pretty good, but I can only speculate why one time, I got a low number with everything compiled into my window manager, while another time, it was dependent on what was compiled in with it.
 
People don't choose a window manager normally because of its ressource usage, but based on its feature set. And more features normally also are equal to more memory usage. This is why this exercise does not make much sense aside when building embedded systems and you really are limited heavily on RAM.

Having said that, there's a window manager missing which is often used for HTPCs - evilwm. x11-wm/evilwm
 
If memory usage of a window manager can be as low as it shows in that graph or elsewhere, I want it to still be comparable to that. I want the underlying wm to be fast and not use much resources. Applications on top are what need to be using the memory.

Thread window-manager-res-memory-usage.81914/ is for RES (resident memory) and possibly other RAM metrics of any window manager. As, the topic of the current thread is specific to TinyWM.
 
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 than 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>

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 :)
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.

If you are lovers to continue to fatten the monopoly buying more and more powerful machines, you will not care about the high consumption of resources and the short life that your machine will have, by the way, there is no software or support for bsd in new machines.
 
Back
Top