Data caching

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, ??

There is something similar yet for a different usecase, the StaticMesh plugin in ParaView, that caches meshes over timesteps.

Caching is certainly useful at many different levels in VTK (point locator caching - as proposed, filter output caching - see StaticMesh, actor caching - for real-time animations, etc.) but the use cases seem to be so diverse that I don’t see how some global VTK caching mechanism could be implemented for all these.

Having several simpler, independent caching mechanisms would be probably easier to develop, debug, maintain, and use. For example, as described above, if we need to share point locator then it could be simply stored in vtkPoints. VTK data object to VBO mapping could be another, completely separate mechanism. says hello