Identifier pass by Value?


#1

Hi Jules,

while scrolling through your commit stream, I noticed you changed the handling of Identifier parameters to pass by Reference.

Why was this necessary and do you recommend doing the same thing in our user code?

I am currently writing some stuff that heavily pushes Identifiers around but I did it the old way (like the almighty master told us to), and now I am afraid of a "search and replace" orgy when I update JUCE to the newest tip :)

 


#2

I liked the by-value style too!

But..

When I first wrote the Identifier class, it was very light to copy - basically just a wrapper around a const char* - and the lifetime of the string was handled by a string pool. So pass-by-value was the most efficient way to do it.

I had to change the class so that it now contains a String instead, and any copying adds the overhead of atomic ref-counting. That's usually OK but we hit some performance problems in heavily-used ValueTrees and NamedValueSets that showed that using it as a pass-by-value type can be a significant problem in some situations. Changing it to const refs made a massive difference to our app here.

So yes - the current advice is to use const ref& when passing them as parameters in performance-critical code. In non-performance intensive code, don't worry about it!

 


#3

Why the change from the string pool implementation?


#4

Because the string pools could never garbage-collect unused strings, because they weren't ref-counted. That's fine if you use a finite set of identifiers, but we had situations where dynamically generated ones would keep growing the pools.