Export Table only changed params

Hi there,

I like using the tableDAT export method a lot, but what bugs me about it is the cooking time drastically rising with the number of rows in that table, even when just one cell changes.
It would be nice, that only changed rows would be processed, so we could use big export tables without having to drop frames.

Cheers!

Do you have constantly changing vals in your export table? Have you considered using CHOPs to export instead - you can set your chops so that the channel name is the export reference. That might be more efficient if you’re working with constantly changing vals.

They are not constantly changing and I could work around with keeping the tables small (divide bigger tables into a couple smaller), but it would be nice to not have to worry about it.
I use DAT export, because it is not limited to numbers…

Thanks, for the input.

If it is a big table, a one time change to a value can even lead to a stutter…

Been on our list for a very long time now. The new 099 Official has a huge round of performance optimizations mostly focused on per parameter and expression optimizations. But next in line is CHOP channel and DAT cells. Please note these types of optimizations take a lot of R&D time so we have no estimate right now as to when they will be finished.

Thanks Ben, it’s good to know, that it is on the agenda. The expression optimizations are really really great! I tried to make a comparison of different techniques (although I think Matthew, already did this a while ago) and it looks like storage or class properties are a good way to go at the moment.
What I find a bit confusing right now, is that we can check, if a parameter is optimized, but not if it is cached. In my test the storage and properties methods, show an “unoptimized” in the parameters, but I guess because they are cached, they are fast as well. Is that correct?

Cheers, David
Export_Alternatives.6.toe (11 KB)

So not all expressions can be optimized (e.g. one that uses built in python libraries), but all expressions are cached, regardless of whether they are optimized or not. If a parameter value is dirty, it’ll be evaluated and cached the next time it is used. In 099.10k , if you have a time dependent node that cooks every frame, and one of its parameters is something like ‘parent().par.tx’, that parameter is evaluated every time the node cooks. In 099.20k, that parameter is only evaluated when the parent’s tx parameter changes, even though the node itself is cooking every frame. The parameter is optimized and cached.

Hope this clarifies the issue.

That clears it up quite a bit.

Thanks Selina!