This page holds testimonies regarding how well Blackbox performs, in general as well as particular situations. You can add (links to) benchmarks, maximal and minimal figures, resource consumption and so on and so forth.
Please, always try to provide some kind of proof or at least some arguments to back up your claims. If possible, tell people how to replicate your test conditions so they can verify your results and perhaps convince themselves.
- 1 Regular, every-day resource consumptions
- 1.1 Memory usage
- 1.2 CPU usage
- 2 Optimization
- 3 Extremes
- 3.1 High resource consumption
- 3.2 Low resource consumption
- 3.3 Low power hardware
- 3.2 Low resource consumption
- 4 Benchmarks
- 1.1 Memory usage
Please note that it is pretty hard to estimate accurate RAM consumption. The usual tools (top, ps, xrestop) will report inaccurate results, because they usually err on the side of overstating, due to the way memory allocation works on most commonly used operating sytem. It's difficult to accurately estimate or interpret memory that is shared among various libraries, dynamic modules and all kinds of other resources.
Here is output from top which shows Blackbox consumed resources at a random chosen moment:
[ciprian] ~> top -b -n1|egrep "blackbox|PID" PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4411 ciprian 16 0 6108 3928 4892 S 0.0 1.5 0:01.53 blackbox [ciprian] ~> cat /proc/meminfo|grep MemTotal MemTotal: 256816 kB
As you can see, Blackbox appears to use 1.5% out of this computer's RAM, which is 256 MB. That amounts to about 3.84 MB. That's also about the amount in the RES column, which shows the "resident" amount (ie. RAM in use by Blackbox that is not swapped, buffered or shared). That's pessimistic estimate, which is the best tools such as top can do. --CiprianPopovici
One thing that can hope to offer some proper insight into Blackbox memory consumption is a memory profiler. If you know how to read them, here's a reading done with massif:
pmap is a Solaris utility which displays information about application address space segments. There's also a pmap version for Linux* created by Andrew Isaacson. This is a more accurate way to examine the memory used by a process. Here's the output from pmap under Linux 188.8.131.52:
$ pmap 10189 /home/ciprian/bin/blackbox/bin/blackbox(10189) 08048000 (372 KB) r-xp (03:07 1901012) /home/ciprian/bin/blackbox/bin/blackbox 080a5000 (4 KB) rwxp (03:07 1901012) /home/ciprian/bin/blackbox/bin/blackbox 080a6000 (912 KB) rwxp (00:00 0) [heap] b7a4f000 (36 KB) r-xp (03:07 2344106) /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 b7a58000 (4 KB) rwxp (03:07 2344106) /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 b7a59000 (8 KB) r-xp (03:07 4672539) /data/fonts/fixed/8x16.pcf.gz b7a5b000 (136 KB) r-xp (03:07 4672730) /data/fonts/microsoft/verdanab.ttf b7a7d000 (140 KB) r-xp (03:07 4672729) /data/fonts/microsoft/verdana.ttf b7aa0000 (8 KB) rwxp (00:00 0) b7aa2000 (8 KB) r-xp (03:07 983242) /lib/tls/libdl-2.3.5.so b7aa4000 (8 KB) rwxp (03:07 983242) /lib/tls/libdl-2.3.5.so b7aa6000 (1204 KB) r-xp (03:07 983239) /lib/tls/libc-2.3.5.so b7bd3000 (20 KB) r-xp (03:07 983239) /lib/tls/libc-2.3.5.so b7bd8000 (12 KB) rwxp (03:07 983239) /lib/tls/libc-2.3.5.so b7bdb000 (8 KB) rwxp (00:00 0) b7bdd000 (40 KB) r-xp (03:07 1655601) /lib/libgcc_s.so.1 b7be7000 (4 KB) rwxp (03:07 1655601) /lib/libgcc_s.so.1 b7be8000 (4 KB) rwxp (00:00 0) b7be9000 (144 KB) r-xp (03:07 983243) /lib/tls/libm-2.3.5.so b7c0d000 (8 KB) rwxp (03:07 983243) /lib/tls/libm-2.3.5.so b7c0f000 (116 KB) r-xp (03:07 1624157) /usr/lib/libexpat.so.1.0.0 b7c2c000 (12 KB) rwxp (03:07 1624157) /usr/lib/libexpat.so.1.0.0 b7c2f000 (76 KB) r-xp (03:07 1624967) /usr/lib/libz.so.1.2.3 b7c42000 (4 KB) rwxp (03:07 1624967) /usr/lib/libz.so.1.2.3 b7c43000 (52 KB) r-xp (03:07 1704155) /usr/X11R6/lib/libXext.so.6.4 b7c50000 (4 KB) rwxp (03:07 1704155) /usr/X11R6/lib/libXext.so.6.4 b7c51000 (796 KB) r-xp (03:07 1359918) /usr/X11R6/lib/libX11.so.6.2 b7d18000 (16 KB) rwxp (03:07 1359918) /usr/X11R6/lib/libX11.so.6.2 b7d1c000 (424 KB) r-xp (03:07 2068585) /opt/freetype2/lib/libfreetype.so.6.3.7 b7d86000 (28 KB) rwxp (03:07 2068585) /opt/freetype2/lib/libfreetype.so.6.3.7 b7d8d000 (4 KB) rwxp (00:00 0) b7d8e000 (32 KB) r-xp (03:07 1738516) /usr/lib/libXrender.so.1.3.0 b7d96000 (4 KB) rwxp (03:07 1738516) /usr/lib/libXrender.so.1.3.0 b7d97000 (164 KB) r-xp (03:07 1624455) /usr/lib/libfontconfig.so.1.0.4 b7dc0000 (20 KB) rwxp (03:07 1624455) /usr/lib/libfontconfig.so.1.0.4 b7dc5000 (4 KB) rwxp (00:00 0) b7dc6000 (72 KB) r-xp (03:07 1622113) /usr/lib/libXft.so.2.1.2 b7dd8000 (4 KB) rwxp (03:07 1622113) /usr/lib/libXft.so.2.1.2 b7dd9000 (844 KB) r-xp (03:07 1623312) /usr/lib/libstdc++.so.6.0.7 b7eac000 (20 KB) rwxp (03:07 1623312) /usr/lib/libstdc++.so.6.0.7 b7eb1000 (20 KB) rwxp (00:00 0) b7eb8000 (4 KB) rwxp (00:00 0) b7eb9000 (8 KB) r-xp (03:07 1754910) /usr/lib/gconv/UTF-32.so b7ebb000 (8 KB) rwxp (03:07 1754910) /usr/lib/gconv/UTF-32.so b7ebd000 (32 KB) r-xp (03:07 1624267) /usr/lib/libXcursor.so.1.0.2 b7ec5000 (4 KB) rwxp (03:07 1624267) /usr/lib/libXcursor.so.1.0.2 b7ec6000 (8 KB) r-xp (03:07 2344102) /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 b7ec8000 (4 KB) rwxp (03:07 2344102) /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 b7ec9000 (240 KB) r-xp (03:07 1901000) /home/ciprian/bin/blackbox/lib/libbt.so.0.0.0 b7f05000 (4 KB) rwxp (03:07 1901000) /home/ciprian/bin/blackbox/lib/libbt.so.0.0.0 b7f06000 (4 KB) rwxp (00:00 0) b7f07000 (84 KB) r-xp (03:07 1655624) /lib/ld-2.3.5.so b7f1c000 (8 KB) rwxp (03:07 1655624) /lib/ld-2.3.5.so bff07000 (84 KB) rwxp (00:00 0) [stack] ffffe000 (4 KB) ---p (00:00 0) [vdso] mapped: 6292 KB writable/private: 1232 KB shared: 0 KB
As you can see from the last line of the output, the private, Blackbox-only memory amounts to only about 1.2 MB.
First, please note that what's inside the windows has nothing to do with Blackbox. It is a window manager and it's only job is to properly draw window bars and borders as well as maintain the desktop background. Updating the insides of a window is the contained application's job!
It's not uncommon to notice an application which gets tied down in some kind of resource starvation, at which point you'll notice that even if the application lags behind, the actual window around it still appears and updates fine. That's Blackbox doing its (separate) job.
As far as CPU usage is concerned, Blackbox was designed to require very low amounts of CPU power, which makes it suitable even for old machines. This has always been a goal of Blackbox.
Based on casual, every-day observation, one can see that even during CPU intense operations, such as compilation, Blackbox will continue to manage and draw windows properly. It's safe to say that you need a really scorching kind of CPU consumption before you will notice any lag in the way Blackbox updates the windows.
- Note: When testing frantic resizing or moving of windows, please do so over an empty desktop, preferably without icons either. Doing it over another window, toolbar or over icons will cause the application owning that window or icons to consume CPU itself due to its own refresh. Also, test resizing or moving a window which doesn't consume a lot of resources itself, such as an xterm. And remember that these are not "serious" tests by any means.
- The most CPU usage I've seen was up to about 1% (as reported by top) on a 1.5 GHz Athlon, caused by frantically moving a window around the empty screen. --CiprianPopovici
- The most CPU usage I've observed today was about 40% (as reported by top) on a 1.5 GHz Celeron, caused by frantically resizing an aterm window. --WojciechPolowczuk
The following is a list of things that Blackbox does in order to speed things up and reduce resource consumption.
- It doesn't use any kind of image loading. It renders graphics programatically via its internal graphics code.
- It caches graphics that take extra-effort to generate (such as gradients).
- The graphics cache is limited to 2 MB.
- It renders the button icons using hardcoded, 1-bit, 9x9 pixel bitmaps, scaled programatically on the fly.
- It frees the memory used by the slit or toolbar completely when they are not used. For toolbar, this happens when the user voluntarily disables it. For the slit, it happens when there are no dockapps using it.
Reports about the biggest amounts of memory or CPU you've managed to make Blackbox use. Don't forget to explain what you did, under what conditions and how you managed it!
Reports about cases where Blackbox's low CPU and/or memory requirements really made the difference.
- The MusE sequencer recommends Blackbox* in order to come as close as possible to realtime processing.
- Blackbox is the Linux window manager of choice* for the Thinstation thin client.
These section holds reports about the lowest kind of hardware (in terms of computing power) that people have managed to use Blackbox on while still maintaining an enjoyable user experience. See below.
- Blackbox is the window manager of choice for the Intimate Project*, which offers Debian packages for use on the Compaq iPAQ* handheld devices.
- Matchbox: Window Management Not for the Desktop* paper by Matthew Allum which tells why Matchbox* was created. It mentions that Blackbox was considered for handhelds, among other light window managers, and how it measured up. It's worth noting that Blackbox was rejected due to lack of handheld-specific features, not performance.
- I used Blackbox on a 486DX4 (66MHz) with 16MB RAM for years. Worked nicely.
- Building Your Own (Minimal) Operating System* is an OSNews* article detailing the building (and satisfactory use) of an almost complete desktop system based on a Pentium II Celeron 300A* (300 MHz). Blackbox was chosen as the window manager.
- Chris Angelini describes* how he chose Blackbox for his PPC laptop, an Apple Pismo PowerBook* (400-500MHz PPC).
- Blackbox happily ticks along on my Toshiba Tecra 550CDT (Pentium MMX @ 266 MHz, 48 MB RAM). --Raj
Reports about all kinds of artificially-induced stress testing conditions.
- Here is a syntetic benchmark* which tests the raw window-mapping power of Blackbox.