CPU readings of JuceDemo on iOS


#1

Hi,

I was checking the iOS demos available on the juce-grapefruit-osx examples folder.

A few wild CPU readings on XCode7 did strike me especially these on the JuceDemo;

- The multitouch demo reads %97 CPU with a two finger continuous drag on the iphone screen. And definitely the UI experience gets sticky soon after. (assuming any audio process would cut at this CPU reading)

- The synthesizers demo hits easily %50 CPU while playing the sine wave tone over the virtual keyboard on the screen. It seems to be a monophonic synth player.

There are other weird heavy CPU readings on other demos. I understand that the 2D graphics rendering would take CPU as well, but this is far then expected in my opinion. I am using an iPhone6 btw.

I have experience on app development with Objective C / iOS platform using CoreAudio, and I would be happy to read an explanation for this situation. 

I want to release an iOS version of my VST/AU plugin developed with Juce, and therefore would love to keep any advice under consideration before starting importing the code. 

thanks,

Sinan

 

 

 


#2

When you're asking about performance (here or anywhere else!) the two golden rules to be taken seriously are:

1. Make it clear that you really were testing a release build, not a debug build, and say what optimisation flags you were using.

2. Use a profiler to be specific about where you think the problem is, because on a multi-core system a global percentage CPU level has little meaning.

The multitouch demo is a bad example - obviously it'll draw as fast as it can without worrying about how much CPU it uses, and if you keep dragging for a long time then it'll be building up hugely long polygon paths to render per frame, which will have terrible algorithmic complexity. It's a naive demo to show how to track touch events, it was never intended as a benchmark and clearly isn't code you'd use in the real world. And no, nothing on the GUI thread will interfere with audio performance, which happens on a high priority thread.


#3

Hi Jules, 

Thanks for the answer.

- I am on release build with an -O3 optimization flag. Not much else to do on Xcode.

- So we agree that the multitouch demo has flaws and shouldn't be considered as good example of optimized code for what is does.

I am pretty sure that Juce delivers what it should do especially on audio performance, however there are tricky things on iOS about UI performance and graphics coding which at least I have learned by experience, and do follow when I do Objective C coding using Apple frameworks.  

I will dig in further on your synthesizers demo and and share a report what it comes up. Yes, I will look as well to profiler, but the CPU reading has still some meaning. Again my attention is on the behavour in iOS. 

 

regards


#4

Thanks, but bear in mind that really nothing at all in the demo app is valid benchmarking material for CPU load. It was all written for clarity, or to illustrate a point. Even the synth stuff. You'll be misleading yourself if you treat it as a reference for this kind of thing.

And even in the rendering demo page, which does some benchmark timing for primitive rendering ops, its overall CPU is meaningless. It runs as fast as it can, regardless of what it's measuring.

I get the impression that you're looking for some kind of overall "how efficient is JUCE" measurement, and just to avoid any FUD in other people reading this, want to make it clear that that's just not something that could be judged for a wide-ranging library like this.

But we go to a lot of trouble to make things as efficient as possible, and many high-performance apps run on our platform, so are always happy to know if you spot a specific bit of code that we could improve.


#5

I've experienced similar problems. I'm building an OSX/AU/iOS app and the CPU utilization for the OSX is about 5% Max, but the iOS version is about 40%. 

It is a monophonic wavetable synth so I dind't expect 44% CPU utilization on the iOS. 

Other than the two things you mentioned about being in debug mode and a profiler are there any other hints at iOS CPU?


#6

Hi,

What iOS device are you using? They obviously have very different performance (as do Macs), so not sure what you're comparing here.

That being said, the same code causing 40% CPU load on an average iOS device and 5% CPU load on a Macbook does sound about right to me.

Bear in mind that iOS devices have variable CPU speed. For example, if you touch the screen a lot and keep the GUI busy, the CPU is kept fast by the device and your CPU load could go down. Conversely, if the app sits idle and does some non-GUI computation without user interaction, the device will throttle the CPU speed and then the CPU load will increase massively.