Well this is quite shocking. I decided I would have to endure the horrific task of bisecting the JUCE repo in order to find the point at which the cpu increase occurred. Thankfully, I had a hunch to try commit 70ddcd which is the commit: APVTS: Use atomic floats for current parameter states
I can confirm that commit eb780b (the one right before 70ddcd) has 9% CPU in iOS and commit 70ddcd (including atomic* and unique_ptr changes needed) has 19% CPU! So my bisection task has been graciously terminated.
Is there a chance that all these atomic* are resulting in a CPU increase? I really have no idea.
Anyway, I’m considering using the latest JUCE revision but reverting (or trying at least) the changes made in commit 70ddcd to see if I can have a working solution with the CPU performance I used to have. Can anyone at JUCE think of a reason why not to do this? I really need to use the latest JUCE revision as for some reason the old May2019 revision no longer works for android (null pointer exception that I can’t seem to fix).