Does the length of the string in ParameterID have any impact on the performance of working with AudioProcessorValueTreeState? Such as getting, searching, comparing parameters? For example, is there a difference when defining it as “mct” vs “MasterCompressorThreshold”?
I declare IDs as static char* with the helper
#define DECLARE_ID(str) static constexpr const char* str { #str };
it’s considered best practice to put all parameter pointers into member variables of the processor at init, so that you don’t even have to use the strings in processBlock. you can get a very string-y workflow by using an array of parameter pointers alongside an enum or enum class though
Thanks for the answer, now I see that I was imprecise. On the audio thread, I use it exactly as you suggested. But I meant using it on the main thread, for example when calling apvts.getParameter(). With the fact that it is almost 5000 parameters in apvts.
Have a look at the sources. It uses a std::map
The lookup time in std::map is not dependant on the string length, if you disregard the trivial process of creating the hash.
Would std::unordered_map be better? It’s apparently many times faster when there’s a lot of data.
I’ve used it myself in something unconnected to parameters, and it works great.
