Performance Considerations

It's almost a requirement to mention this, as one of SysMetrix's uses is to measure system performance. You obviously don't want your measuring tool to bog down your system or it will affect the measurements and you won't really want to use it very often. I'd love to say that it's the slimmest, lightest, fastest metering program out there, but that's just not true. Having said that, I've spent a great deal of time profiling and optimizing it. In my opinion it does a pretty darn good job of not consuming a ton of CPU cycles. Yes, it's written in Visual Basic which means that it will consume some memory, but all of the core performance-draining routines use the Windows API calls pretty much exclusively so in the end it's pretty darned close to what a C program would be like. Additionally, you (and/or whoever creates a theme) can also control how much the program does and how often it does it. By way of example, it obviously has to work much harder if it updates all the information every second compared to if it only updated it every five seconds. That said, most computers ought to be able to handle a one second update with ease. In the same vein, if it's updating tons of statistics and drawing a bunch of large histograms every second, that takes a lot more effort than reporting on just a couple of items. In a nutshell, depending on the complexity and physical size of the theme, SysMetrix may take up some of your precious CPU cycles. Hopefully you'll agree that the tradeoff is worth it. Here's a short list of some of the most cpu-intensive things: Clock hand anti-aliasing. This shouldn't be too bad unless the clock hands are large. You'll generally want to leave this on unless you've got a really slow system since the effects are very nice. Large clock hands. This gets more expensive as the hands get larger because a lot more work has to be done if the hands are anti-aliased. Again, this won't be a consideration most of the time since you probably won't be creating a huge clock. Drawing hour numbers and hour markers. These should really be done in the background image instead of making the program draw them every time. They are offered so that you can whip up a decent looking clock given an existing image. Drawn histograms. Image-based histograms are much faster due to the way that they are internally implemented.  Windows can copy bitmap images in memory very quickly and efficiently. Wide histograms. A histogram's width determines its 'history'. If a CPU monitoring histogram is 75 pixels wide, then it will display the CPU usage history for the last minute and 15 seconds. The wider the histogram is, the more history it has to keep track of and plot. As the width increases, the amount of work that SysMetrix has to do to maintain and plot the information increases.