I just got one of my computer’s fans repaired. It was still working, but noisy like a diesel engine. While I started savoring the relative quietness of my study again, I noticed that I lost something with that repair. I lost a source of information about what my computer is doing.
The fan speed—and noise—varied with the CPU temperature, which in turn varies with its clock speed and workload. The harder the machine works, the noisier it got. At first, you night think (correctly, for that matter) that having a noisy computer is annoying, but I think you can turn that to your advantage while coding.
Having an actual, noisy, grinding fan is an annoyance. But what if we paid attention to the noise our computer makes, use it as a development tool?
It’s easy to forget that a computer is just a machine like any other, and that an intensive computation, in addition of taking time, also consumes power, dissipates heat, and cause wear—especially when disk IO is used intensively. Therefore being aware of what our code does to our computer may make us better coders.
If you don’t benefit from a noisy fan, you can still use the machine’s sensors to keep you informed on what goes on in your box.
- Sensors. You can use Linux’s sensors command to get a snapshot of your box’s health. The package you need to install varies from a distribution to another, on Debian-like it’s the package lm-sensors. Invoking sensors, maybe within a pretty-printing script, combined with watch (say, watch -n 1 sensors) will let you see what happens.
- htop, iotop, and nethogs. htop is a prettier, configurable, version of top. It does the essential: processes, process trees, threads, etc. The iotop command needs to be run as root, but will show you what happens with disk IO. nethogs does the same thing for network bandwidth.
- Conky and other system monitors. A good while ago, I wrote a piece on conky, a simple but highly configurable system monitor. It’s kind of old school (no rounding plasma 3D widgets) but gets the job done. I’ve integrated sensors to it so it also displays the CPU temperature and fan speeds.
Listening to your computer doesn’t replace good software practices (good algorithms, profiling and hunting for hot spots) but complements them. If you hear your HD scratching a whole lot more that it should, you have gained a few bits of information—something unexpected is happening.
In a way, that noisy fan helped me refine my code in more than one occasion. It reminded me that I should be coding for a Pentium III (something I think I advocated before), and that if my program was making my computer noisier, then it probably consumed more resources—CPU, IO, power—than it should have. Keeping my computer quiet forced me to write better, faster, more frugal code.
Keeping an eye on the machine exertion symptoms may help you write better code, especially when scaling is considered. If your program adds 20 degrees to your computer’s internal temperature, how will it scale to service a hundred time more requests?