Achieve Pidsley Level (Rape my RAM)

[wuxmedia]

neat - i'm enjoying the energy...
might even participate.

[DebianJoe]

Okay, setting your background via SCIENCE!

Since it only makes sense, I am removing all of the non-winners from my test box as we go. So, now I've got in my .xinitrc:

Code: Select all

foobar_wallsetter ~/path/to/whatever
exec aterm

So, the only thing changing here will be the thing that we're testing, and the winners get to stay while I vote the losers off of the island.

This time, wallroot setters. The scores on this one were MUCH closer than in the terminal emulator tests.


Pidsley Scores

Code: Select all

feh   =    0
esetroot = 464
hsetroot = 796
xsetroot = 1100

It's probably worth mentioning that xsetroot sets only colors, while feh/esetroot/hsetroot can set images. Still, this is about the MOST basic way to do this. Obviously, I could also have downloaded Nitrogen, but this is a "best-of-the-best" contest...and anything I use in these tests is something that we'd probably call a more minimal approach. I didn't test Terminator either, but it would most likely have a Pidsley Score > 9000.

xsetroot wins. (#87CEFF it is, then...)

[GekkoP]

Nice work, DebianJoe. Those Pidsley-scores absolutely convinced me to give aterm a try. Keep going!

[machinebacon]

Excellent, and hey it really does make a difference! I'm loving it!

Before you move on to the world of WMs, let's throw an eye on gtk themes. I know, it's not really the first choice of hardcode UNIXers but there are some apps that do use GTK, and there are performance differences between the themes. If you have time and interest, you could compare the engines (murrine, Mist, Crux), though it will be hard to pin down differences in RAM, I suppose. OTOH, there *must* be a difference. IIRC, and my brain doesn't fuck me very often, exactly Mist-based themes were quite snappy. Let's not go into gtk3, though.

[DebianJoe]

That one may take a bit of reading on my part first Grillmeister. I don't generally use gtk at all unless I need it for something like the Roaster project. I'll do some reading on the differences and how to set-up/remove each of them for a "one at a time" test. I will also have to come up with a decent way to track spikes, because once they're done rendering, they will probably level out a good deal.

...feel free to toss ideas my direction if anyone has them. This is proving to be more interesting than I would have imagined.

[GekkoP]

aterm + hsetroot (because that wall is MY Elektra! :D)

[pidsley]

What needs tested after terms? WMs?

Some preliminary numbers on WMs. This makes even less difference than changing the terminal, if you can believe that. I used my "tiny" install from yesterday, and used Openbox as base. Here are the "pidsley scores" (at least on this setup at this particular time).

openbox 0
pekwm -2816
oroborus 848
jwm 908
dwm 1192
evilwm 1268
fluxbox 1400
lwm 1452
ratpoison 1924
tinywm 1944
cwm 2176
evilwm (no xbindkeys) 2396
tinywm (no xbindkeys) 3124
aterm 3248

"aterm" in this list is no window manager at all -- just aterm started from xinitrc.

[DebianJoe]

nullwm? ;)
Thanks for the help with this project. I am surprised that they're as close as they are. This is proving to be less intuitive than I would have expected.

Note, null is a "manager" in only the loosest of terms. To give it a fair chance to meet the experiment, I'd need to rewrite it to use aterm instead of xterm, or else it would lose due to using a more bloated terminal OOTB.

Edit: I'll set up CWM and null, and use the difference on my system to see how it compares. Any other options that deserve a shot? tinywm?

[pidsley]

nullwm? ;)

To simulate what nullwm does, I simply added "exec aterm" to .xinitrc, in place of any window manager (this works perfectly well to start a single aterm window in X). I left all the other code alone (it still gets a background and sources .Xresources). I added this to the list, but you're right that this (and nullwm) isn't really a window manager because it does not allow any resizing, tiling, or switching between windows.

(edit) also added tinywm. maybe some heavier wms next like pekwm and fluxbox :)

[GekkoP]

By the way, I tried sh as login shell as you suggested, Pidsley. RAM usage dropped to 41MB. You're the man!

[DebianJoe]

Wow....I'm REALLY surprised to see cwm pull ahead of tinywm. Especially having been through the source for both of them, but it goes to show you that it isn't just lines of code, but how elegantly they work in execution. (Try moving a large window in both of them, cwm handles that drastically better.)

Thanks again for the numbers pids. I'll leave WM's up to you, as you've up a very nice precedent for what the standards should look like, and obviously no two systems will be totally identical. I'm going to get back on gtk2 engines.

[pidsley]

I'm about to add a couple more to the list -- of course, the real test of a WMs "lightness" should be how it does when several windows open running different things. I expect this might make a little more difference than just how much the WM starts X with. But that test would be much more difficult to set up, and subject to a lot more variables.

BTW Joe, one reason cwm does so well it that it doesn't need xbindkeys running. Without xbindkeys tinywm pulls just slightly ahead of cwm, but it's much less usable. evilwm without xbindkeys is also a little lighter than cwm. I added these to the chart.

[DebianJoe]

^^ That's part of the reason that I used the Xkeysym in Null, to get around the xbindkeys caveat. I'd agree that the real test of the WM is multiple windows. Still, with the fact that tinywm attempts to redraw the entire window at whatever the screen refresh rate is, that it's not the "lightest" decision, despite the fact that it is a drastically smaller program base.

[pidsley]

If all you want to do is start one X terminal window with emacs in it, you don't need a window manager at all.

[DebianJoe]

I'm guessing, "exec aterm -e emacs -nw" in .xinitrc would get that done. :D

Edit: also, you could always pass arguments for geometry as well. I guess that totally deprecates my silly project. :P

[pidsley]

I'm guessing, "exec aterm -e emacs -nw" in .xinitrc would get that done. :D

Yes. That's how I got the "aterm" number in the WM chart (without emacs, of course).

[DebianJoe]

If you'd read the post that I started with, I was using the same method to launch the terminal emulators in X...but I hadn't considered simply chaining the processes together. That's probably the MOST minimal that X can be and still be usable. With the base window being a terminal, I also would imagine that you could launch each and every program that could be used from said window. That's not how I'd choose to do it, but if you're going for extremes...I can't think of a smaller way to get it done.

[pidsley]

^ yes, you could, but each program would launch on top, with no way to select within the stack or resize the windows. With appropriate geometry settings you could do a sort of tiling, but I think there's a limit to minimalism...

[DebianJoe]

...but I think there's a limit to minimalism...

As do I.

I am glad that you included the aterm-only option vs wm's, though. It gives a decent frame of reference as to what the user is sacrificing in resources for the convenience of being able to move windows around. It's really not very much, and it's WAY more significant than the differences in operation between aterm and xterm.

[ivanovnegro]

Oh, that is a crazy hell here. :D I love it.