AudioProcessorValueTreeState performance?

[gavinburke]

Have been investigating the AudioProcessorValueTreeState.

One thing that I noticed is that it does a string compare of the paramID using linear search when you want to set/get the value. This is totally fine for a small plug-in, I’m wondering how this would scale in a complex commercial product where you might have upwards of 5000 parameters. I’m thinking of a situation where a slider is being adjusted and it is firing off multiple set parameters and each time it is running through all 5000 for a match using a string compare. An integer paramID that would index directly into the array of parameters would be a lot better? Also, how does it work on preset load? Maybe I’m overly concerned about performance!

[ttg]

Performance of APVTS is critical on your DSP thread (AudioProcessor).
That’s why you’ll see also on JUCE’s own example the use of getRawParameterValue() . so for the actual calls even if you need parameter to be read every sample you’re using simple pointer.

[lalala]

@Gav

One thing that I noticed is that it does a string compare of the paramID using linear search when you want to set/get the value.

perhaps you can keep a pointer to your AudioProcessorParameterWithID (which is returned by AudioProcessorValueTreeState::createAndAddParameter()) and call getValue() directly on it if you want to avoid the paramID search ?

But one thing that is a bit cpu heavy however is the call to NormalisableRange::convertTo0to1()
every time you call AudioProcessorValueTreeState::Parameter::getValue()