Caching Data for Iterative Jobs

I have some iterative jobs that depend on the results of the previous run. These are things like feedback loops and integrators/accumulators. I know I can create an entity to hold the intermediate result and read that on the next iteration. I'm looking for a way to avoid that overhead and just "pin" a variable that persists across iterations that is directly accessible to the job, so I can read and write to it on each job iteration. Most commonly, I just need to hold a single value (usually a float) for a single (non-parallel) job. Of course, more general approaches that can hold structs for jobs running in parallel would be useful. In parallel cases, each parallel job would only access its own instance of the variable/struct.

 

Can't you just have a persistent NativeArray in the system, and pass it to the jobs ?

 

By "system" I assume you mean the class with the job and not the overall system. I thought about something like that, but wasn't sure how to handle disposal. It seems I would need some way to hold a reference to the array outside of the system so I can dispose it when I know the system will no longer be used. Or, I would need to manage the overall lifecycle of the system. Kind of like a "sticky" system - I would manually instantiate the system and create the array in the constructor. Then I dispose of it in the destructor when I release the system. I'm worried about how that might mess with the internal JCL processes though.

I was thinking of creating an in-memory cache and defining an attribute like [Persist <key>]. That still doesn't help with disposal, but would help as a general solution. (And, I don't really know to implement something like the cache).

 

OnCreate() and onDestroy() are there for that

Code (CSharp):

1. protected override void OnCreate()
2.         {
3.             _sources = new NativeList<int3>(Allocator.Persistent);
4.         }
5.         protected override void OnDestroy()
6.         {
7.             _sources.Dispose();
8.         }

 

Cool, thanks. And the system gets created and destroyed once per application run? I didn't know if it was recreated on each frame/sim step, loosing the list contents.

 

yes, per application run .