[request] Caching

[Billiam]

Currently, when iterating on code in the workbench or when changing parameters, the kernel needs to redo the same operations over and over, so that changing one parameter, or a line of code at the end of a project requires a full rebuild. This can be very slow for some projects with complex geometry and/or text.

I think it could be helpful to maintain some kind of state or operation cache, so that expensive operations, like complex booleans, would not need to be performed again unless their inputs changed.

Cascadestudio handles this use case with this CacheOp method, which serializes the incoming parameters, stripping the pointer IDs from open cascade objects, and just stores the results in a cache object.

[sgenoud]

The way cascadestudio does caching is partially the reason I built replicad - it forces the system to be more integrated as a framework (instead of a library).

That said, caching is very useful, not only for the case you mention, but also to make configuration changes faster.

What about using javascript and the libraries that exist?

I did a quick hack:

const { makeBaseBox } = replicad;
import memoize from 'https://cdn.jsdelivr.net/npm/memoize@10.1.0/+esm'


function memo(fn, memoName) {
  const name = memoName || fn.name
  if (!("cacheMem" in globalThis)) {
    globalThis.cacheMem = new Map()
  }
  let cache;
  if (globalThis.cacheMem.has(fn.name)) {
    cache = globalThis.cacheMem.get(name)
  } else {
    cache = new Map()
    globalThis.cacheMem.set(name, cache)
  }
  return memoize(fn, {cache})
}

const newBox = memo(function newBox (width) {
  console.log("new box")
  return makeBaseBox(width, 50, 10)
})

export default function main() {
  let base = newBox(50);
  return base
}

Note that you could get a bit more in depth (i.e. use the code as the function key, have a LRU cache, do some magic with the replicad objects).

But this could all be packaged as a library to import instead of being part of the workbench. Obviously, this is not working without any input from the user - but it gives more detailed control (which tends to be useful when caching as invalidation is not always easy)

Do you see another issue with this approach?

[Billiam]

I think it's possible this could be done from userland javascript, so it may be a matter of getting some more guidance, and/or supporting API features to make it effective?

I ran into a couple of issues with a similar approach earlier:

With the example you gave, if the main looks like this:

export default function main() {
  let base = newBox(50).translateZ(10)
  return base
}

and I then change the translation from 10 to 11 (use a parameter for it), replicad throws an This object has been deleted error.

The other issue I ran into (and which might be covered by "some magic with the replicad objects"), was that the most expensive operations have mostly been boolean operations, and I think that will require some kind of custom serializing for a cache-hit.

[sgenoud]

might want to return clone of the objects (sometimes the objects are deleted):

let base = newBox(50).clone().translateZ(10)

Ideally this would be part of the memoization routine...

For the boolean I would potentially see to create some memoization keys that depend on the parameters of the shapes being fused.

Note that I don't like any of these solutions. Part of the reason I have not attempted this is that I know it is hard and very prone to bugs...

[Billiam]

newBox(50).clone()

I'm not sure. So far, on a successful cache hit, the shape has already been deleted and the clone fails. Possibly they need to be cloned when saved to cache as well as when returned from the cache.

memoization keys that depend on the parameters of the shapes being fused

Do you mean that (potentially) the parameters that went into creating the shape (ex: the x/y/z lengths for a basebox) would need to be preserved so that they could be passed to the caching function?

I think that could work for simple primitives, but would become more complex pretty quickly for a shape created from a series of boolean operations, but maybe that's the only option.

I'm wondering if a shape can generally be serialized by it's edges. For geomType == "LINE" edges, I think shape.repr may be enough, but I'm less clear on how to serialize more complex types (like BEZIER_CURVE, EXTRUSION_SURFACE or OTHER_CURVE) 🤔

[Billiam]

The other (general) issue with this approach is just the interface, since it:

1. requires defining any method that could be cached and
2. changing out calls from more convenient object.fuse(other) to fuse(object, other) (or extrude, chamfer, fillet, etc), creating deep paren chains that are harder to read and reason about.

Do you suppose that something could be added to the replicad interface to make injecting a caching method more straight forward, to allow the existing chaining?