Pass ValueTree by Value 4x slower & allocates

General JUCE discussion
1

We recently updated to JUCE 7.0.12 from JUCE 7.0.7.
And we realized that all ValueTree related functions now run four times slower. And it affected our UI.

We did some profiling. And it seems to change happened in JUCE 7.0.10. Because in JUCE 7.0.10 ListenerList code was modified. As a result passing a ValueTree by value now allocates memory. Which it did not before, as far as I can tell. Here is a screenshot off the call stack:

image
image1649Ă—549 138 KB

As you can see it is calling std::make_shared. This call stack is from passing a ValueTree by value.

In our case we should be able to solve the problem by restructuring or ValueTrees. Which is over due for many reasons. But I still found it a bit curious that passing a ValueTree by value now allocates memory.

EDIT: @pflugshaupt did a more thorough analysis of before/after than I did.

6 Likes
2

I imagine this should be lazily initialised as in many cases you won’t need a listener list.

2 Likes
3

Before this change, there was just an Array with pointers to the listeners… so passing by value did create a new Array and copy the pointers… which also allocates memory. Maybe that slowdown you are seeing is just from the extra logic of the shared_ptr ? It seems that using a shared_ptr would allocate less memory than creating another Array with all the entries.

However on second thought, the problem is probably what happens if there are no listeners in the list (which should be the case for a ValueTree passed by value). This was fast with a plain Array and now goes through the whole shared_ptr logic.

As dave96 wrote… it would be good if listeners was optional as it is likely unused in most ValueTree instances.

4

My understanding is that shared_ptr itself would be fine. The problem is calling std::make_shared on construction, instead like @dave96 suggestion where the listeners vector would be created on demand.

BTW, I think the problem is in ListenerList (which is used often in JUCE) and not ValueTree itself which is intentionally not copying the listeners in the copy constructor.

1 Like
5

Ah, I see.
Thanks for digging deeper than I did, Pflugshaupt.

6

not deep enough :wink:. eyalamir is right… the list was left out on purpose in the copy ctor… I looked at the header only :smiling_face:

1 Like
7

Thanks for reporting, I’ve pushed a commit aiming to address this here

3 Likes
8

Unless you use a lot of CachedValue (or anything similar). But I’m not sure if this would damage the performance if you have a big ValueTree for your application - I think, excuse me if I’m wrong!.