diff options
author | David Robillard <d@drobilla.net> | 2016-10-01 15:18:09 -0400 |
---|---|---|
committer | David Robillard <d@drobilla.net> | 2016-10-02 12:24:57 -0400 |
commit | a172e76897157e5a0d2ebd3fa3f7f77ec38a5df0 (patch) | |
tree | afc1962fc5123ff8ad4558912e69227bca2a4192 /tests | |
parent | 5c4356827e51b3d6e1256a050e6273a87728d588 (diff) | |
download | ingen-a172e76897157e5a0d2ebd3fa3f7f77ec38a5df0.tar.gz ingen-a172e76897157e5a0d2ebd3fa3f7f77ec38a5df0.tar.bz2 ingen-a172e76897157e5a0d2ebd3fa3f7f77ec38a5df0.zip |
Defer graph compilation in atomic bundles
This avoids situations like compiling a graph hundreds of times when it
is loaded because it has hundreds of nodes and each event triggers a
re-compile.
This speeds things up dramatically, but exacerbates the theoretical
problem of there not being enough time in a cycle to execute a bundle.
As far as I can tell, the execute phase of events is very fast, so
hundreds or thousands can easily run in a tiny fraction of the process
cycle, but this still needs resolution to be truly hard real-time. What
probably needs to happen is that all context and state used to process
is moved to CompiledGraph and nodes do not access their own fields at
all, but have some references into the CompiledGraph. This way, a
compiled graph is separate from its "source code", and an old one could
continue to be run while a new one is beng applied across several
cycles.
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions