Over the last few months I have been developing my first c++ application in JUCE. For all intensive purposes, the application is a recording application, which synchronously records audio and sensor data (via Serial devices, OSC, and in the future Midi). Audio and sensor data (which is upsampled) is recorded as uncompressed .wav files for my PhD research which involves extracting features from the recordings and performing machine learning experiments.
My app is pretty stable, and I have finished implementing the main features a while back, but currently, I’m at the point where I’d like to clean up the code I “pushed through” to get things working for deadlines, and most importantly, increase performance. Not only was developing this application one of my first full-on c++ applications, but the first time I used Threading, and other things of the sort. I think some of the performance issues I am having might come from my basic understanding and implementation of Threads, and the amount of data being passed into various callbacks and message handling. Any advice you can share would be greatly appreciated!
Here are a couple scenarios / examples where CPU usage seems quite high. Perhaps there are optimizations I can do on my part, or perhaps someone may have a good explanation for the applications behavior / cpu usage, and insight into how I may address these issues, or prevent them in the future.
- I have a modal window / tabbed component which allows the user to enable listening to OSC (network) messages on a specified ip/port. There is also a TextEditor which dumps all incoming OSC messages for the user to preview incoming data, and to make sure the ip/port are correct. The messages come via a standard ChangeListener callback (note, the messages are actually sent/notified via a ListenerList elsewhere i.e. to OSCRecorders as it was much faster and ChangeBroadcaster coalesces messages, however for the TextEditor, it could only print incoming msg’s so fast, and all that data was not necessary for simply previewing the input).
According to Activity Monitor, the application doing nothing runs at about 4% cpu. Opening up the OSC settings window jumps the application to around 15% cpu. Enabling listening to OSC barely effects cpu usage. Sending osc messages every .5 seconds with the window open and printing to the TextEditor barely effects the cpu usage, however, if I send data super-fast, lets say every .5ms my CPU jumps to about 45-50%. Closing the window and not printing to the TextEditor but still receiving the osc messages goes back down to about 14% cpu. Clearly printing to the TextEditor drastically effects CPU. I was wondering if its the painting that causes this or the Changelistener callback?
Everytime I add an OSC Recorder object, it adds about 5-10% cpu usage. Each OSCRecorder visually displays the incoming data with a rectangle/slider, and allows the user to select an incoming message to listen to, and a button to enable/disable recording. I suspect the 5-10% increase in cpu usage is due to the ListenerList message callbacks passing the data to each osc recorder. Are callbacks / data passing generally this intensive or is it my implementation?
Im happy to post code if that would be helpful, but have attached an image to show what Im talking about. I guess generally, I’m wondering if this is typical CPU usage for having callback lots and lots of callbacks, or if it’s poor coding optimizations and implementation on my part. Thanks for your help!