AudioProcessorGraph::addNode performance


#1

Hi,
I have a question about the performance of AudioProcessorGraph.  I've noticed that if I try to add more than a few thousand nodes to the graph, the addNode operations get progressively slower.  It seems like the time to add a node might be proportional to the number of nodes already in the graph.  Any idea why this might be--- is there some kind of check that happens when a new node is added, and do you think it might be something I could disable?

A minimal example of what I'm talking about could be seen in a test such as


AudioProcessorGraph graph;
for (size_t i=0; i<20000; ++i) {
    if ((i & 1000) === 999) {
        cout << "add node " << i << " to graph" << endl;
    }
    // WaveGenerator is just a simple square wave audioProcessor subclass; could be anything.
    graph.addNode(new WaveGenerator());
}

In that example, on my machine (running Linux), making/adding the first 4,000 nodes takes about a second, but making 20,000 nodes takes over a minute.

I'm not sure whether creating 50000 or more nodes would strike people as an unreasonable thing to want to do.  In my case, the reason I believe it might be feasible (i.e. and won't result in far worse performance problems when I actually play back the outputs) is that I'm bypassing most of the nodes at any given time; I'm using nodes kind of like notes in a score.  The reason I'm interested in doing this in the first place, rather than say having a single AudioProcessor which plays all these different notes, is that I might want to have outputs of different notes routed through different effects.

 


#2

I haven't used the graph stuff but I'm pretty sure it was never designed to work with so many nodes.  Most applications would probably only use a hundred maximum.

You probably need to look at your design - consider putting more functionality into each node so you don't need so many.  For example, a synth wouldn't add a node for each voice - instead it would mix all the voices together internally and present itself as a single node in the graph.


#3

Yes,

See http://www.juce.com/forum/topic/chaining-audioprocessorgraphs and the follow up thread: http://www.juce.com/forum/topic/optimisations-renderingopssequencecalculator which contains a version of AudioProcessorGraph which adds nodes much faster… Removing nodes is still slow as discussed in the thread.

Jules should consider adding the changes to JUCE… I’ve tested it extensively and it works well.

Rail


#4

Reducing the nodes isn’t a practical solution… the AudioProcessGraph needs a rewrite (as included in the thread I linked to in my other response).

Rail