I have been testing and I have come to the conclusion that it is not convenient to call the getValue functions repeatedly, for example in a loop, hundreds or thousands of times. Since the drop in performance can be dramatic to the point of consuming all the time available for the audio block.
These functions that I am referring to are
apvts->getRawParameterValue
parameter->getValue (2 times slower than getRawParameterValue)
apvts->getParameterAsValue (4 times slower getRawParameterValue)
One solution is to save the pointer to atomic float at the beginning of the application and access it directly during the process. But since we are repeatedly accessing a value that is being modified simultaneously, I think it is a better idea to save the value in a variable at the beginning of each block.
But this is just my impressions, Maybe I’m wrong about something
why would a string compare that gets the parameter and then calls getValue() on it be faster than just getValue() directly? maybe something about this test was weird
oh i see. in my own parameter class i implemented getValue() to just return the normalized value by simply loading from the atomic float in the class. juce’ parameters have the denormalized value in there apparently. i’d advice rolling your own thing then. if you ever plan to add a parameter modulation system you have to start all processes with normalized values anyway
Most parameter functions (getValue(), etc) all read an atomic value, which is slow and will block the optimizer if used inside a loop.
What you usually want to do is read that parameter value once at the start of the block, and avoid re-calling the function inside some per-sample loop.
That is also valuable for correctness, not just performance - the parameter value could change by the UI/automation during your loop, producing incorrect results.
Calling those getValue functions in a loop can really tank your performance. I’ve had a similar experience, and I found that caching the values at the beginning of each block is a solid workaround.
