Lag when destroying ops

Is there a way to reduce the performance lag when deleting large numbers of ops?

For example, in the RayTK development tool, it can load a tox full of test cases for a given operator. Those toxes contain fairly large numbers of nested operators.

There’s a significant lag when loading, which is a separate issue (likely related to shader compilation).

But there’s also a significant lag (sometimes >30 sec) when unloading (destroying the COMP and its contents).
In the performance monitor, by far the largest chunk is “Destroying Operator”.
There are also large numbers (1000+) of mysterious other entries like:

  • Propagating changes to other nodes (Private operator)
  • Propagating changes to other nodes (…various UI widgets…)
  • Tons of updates to /ui/panes/…
  • Propagating Cell Changes / (COMP:base)

raytk-devel-performance-unloading-test-2022-07-24.zip (11.3 KB)

1 Like

It takes a lot of processing power to silence the screams of all the OPs you are murdering.

I would imagine there could be some performance gains if you don’t mind your computer making a shrieking noise each time you commit these little genocides.

4 Likes

I’ve noticed the weight of these delete operations too. It’s a shame, because building system in touch where the end user can delete/create “objects” usually comps with internal guts is the intuitive and elegant choice but that performance hit makes uis feel sluggish and systems don’t scale as well to larger numbers.

I suspect this is a trade off that we get by having touch be blindingly fast when things are in a static state. Stuff gets cached in the backend I’m sure to make it fast after.

Renaming nodes as I’m sure you’ve noticed hits the system very hard too, as it triggers what is probably a ton of backend cached data, expressions, etc to re-evaluate.

1 Like

Yeah, this is not my area of expertise but I’m pretty sure that changing names and deleting things causes a lot of stuff to have to recook. Thoughts @rob?

Yah, it basically entails updating all the cached dependencies, as well as ‘still-looking-for’ expressions, expressions + node patterns with wildcards etc, etc.
However, there’s always room for improvement, and good test cases always help with that.

Any chance you can either stop cooking when you do all the deletes, or disable some kind of master container? The goal would be to have just one event where everything recalculates instead of for every deletion.

1 Like

Yeah I’ve tried that in a few places. It seems to help a bit, but it’s still not great.

In the RayTK build process (which is one of the major areas where this manifests and is sort of its own separate topic) I’ve been experimenting with different balances of doing more deletes at once vs splitting them into smaller batches to spread over multiple frames. It seems like splitting them helps avoid crashes, but might take longer. Right now I’m using batches of 50 deletions at a time which seems at least somewhat stable even though it stretches things out for a long time.

Since forever I’ve wanted to make a component that would delete one or two nodes per frame, doing it in some kind of right-to-left network order, after disabling all cooking of the nodes, then call a callback when it’s done. A little bet more stealth. Would that be OK for most of you?

3 Likes

That’s the approach that the RayTK build process uses. It works pretty well.
Having that in a reusable component (from someone who understands the internals) would definitely be helpful.

2 Likes