Lately @utkarshayachit, @cory.quammen, @will.schroeder and others, at the prompting of various customers and driving use cases, have been thinking about caching VTK objects to reduce memory usage and improve performance. Here are some examples where caching might benefit VTK:
- Building a vtkPointLocator in different filters from the same vtkPoints object. Points are often passed from input to output, and a filter may build a locator, do its thing, and then pass the points to its output (i.e., the next filter), which may again build another locator - a duplicate of the first locator.
- Ditto for vtkCellLinks, vtkCellLocator, etc.
- Graphics: creating duplicate VBOs from a vtkPoints which is shared across multiple datasets.
At this point we have some half-formed ideas and are looking to develop a good, concrete design and to start implementing something in the near future. So feedback is requested. Here are some thoughts to get the conversation going.
- Maybe a general cache mechanism for any type of vtkObjectBase reference counted object.
- Queries might look like: Is there a <class> depending on these instances <o1,o2,o3,…> with modified times <mt1,mt2,mt3,…> ? If so, return it (the instance of the class).
- Populating the cache might look like:
Insert(<class,classInstance>, <(o1,m1), (o2,m2), (o3,m3), … >) - The cache would destruct and clean up after itself.
- The cache should be usable as a singleton, or multiple instances.
There are other approaches that might be used in conjunction with, or even instead of, a cache. For example, instances of vtkPoints could carry a reference to an associated point locator, etc. which would be passed through a pipeline along with the points.
Comments, suggestions, ??