Cantabile Development Blog

Follow the development of music software Cantabile

Articles | Full Index | RSS Feed


Comparing performance to Cantabile 1.2

Today, out of curiosity I thought I'd compare the performance of Cantabile 2.0 to the previous version 1.2 - and was pleasantly surprised.

For the test I setup a session consisting of a low CPU usage plugin (MDA Piano), followed by a reverb (Kjaerhus' Classic Reverb) and a complex MIDI file (Beethovens Waldstein Sonata) with the tempo tripled. The idea was to try an bias the processing load off the plugins and onto Cantabile.

First I ran the test in Cantabile 1.2 playing the entire MIDI file and observing CPU usage in Windows Task Manager. Not a very quantitative test but good enough for these purposes. On average CPU usage hovered around 10 and 15%.

Next I ran the same test in Cantabile 2.0 and got almost exactly the same result - perhaps a little higher (say 12 to 17%), but not bad considering version 2.0's got quite a lot more going on. For example, there's a lot of alpha blending and image stretching involved in painting the GUI.

So I was pretty happy with this, when it occurred to me that I was running the debug build of Cantabile 2.0. A debug build is a special way of compiling the program that includes additional diagnostic code and isn't optimized by the compiler. Switching to a release mode build yielded CPU usage averaging about 7 to 12%. That's about a 3% improvement which I didn't expect at all (but obviously not complaining about).

Finally, to eliminate the overhead of screen redrawing I ran a similar test in both 1.2 and 2.0 with the main window minimized. On 1.2, CPU usage ranged from about 2 to 6%, whereas version 2.0 was about 0 to 5%. Still an improvement!

In the end I'm extemely happy with this as I truly didn't expect an improvement and was hoping to just match the performance of 1.2.

It did make me realise however just how much goes into re-drawing the UI - about 5%. Perhaps there should be an option to disable various parts of the screen activity. eg: an option to not light up on-screen keys in reponse to incoming or sequencer generated MIDI events. Maybe even just an option to disable all "real-time" screen activity (lighting up keys, MIDI activity, usage and level meters etc...).

Finally I'm still going on the sequencer and have now got it integrated with the metronome tempo slider, keyboard showing notes played by sequencer and fixed a nasty crash in the audio engine's support for multi-core CPUs.

Posted on April 4, 2008

Share This

Posted on April 4, 2008

Larry Allis says:

...re-drawing the UI - about 5%. Perhaps there should be an option to disable various parts of the screen activity. eg: an option to not light up on-screen keys in reponse to incoming or sequencer generated MIDI events. Maybe even just an option to disable all "real-time" screen activity (lighting up keys, MIDI activity, usage and level meters etc...).

I do hope you can provide such a switch to turn off screen activity, at least if it's not too hideously difficult to do.

Gaining 3 or 4 percent could be helpful on marginal systems or those running very many plug-ins.

Larry

Leave A Comment

All comments will be reviewed for spam before being displayed.