Replicad Performance with recently-deserialized shapes

[tristan-huber]

Hi Steve,

We've been experimenting with a serialized cache of brep shapes stored in indexedDB for some of our projects. This has some desirable effects like: allowing multiple workers to operate on the same library of shapes, and persisting project components between loads of the page.

However I've also noticed that the performance of replicad seems to be slower with de-serialized shapes. I'm still digging into exactly where the compute time is going but many operations, especially simple ones like move or rotate, seem to take quite a lot longer when dealing with a freshly de-serialized shape.

So.. my question is this. Does replicad (or opencascade) do any caching internally? For instance if I've just created a shape with extrude, should I expect it to perform better in a cut or intersect operation than if I'd generated the same shape by reading a brep file? Would love to hear your gut feel on this and/or pointers to any relevant code that comes to mind.

It seems likely that something about our frequent serialization and de-serialization is disrupting the internals of opencascade. At this point it appears that we're not actually loosing the time on the serialization/deserializaiton itself but rather experiencing slower geometric operations.

Also tagging #207 as related

Thanks!
-Tristan

[sgenoud]

The only thing I know of is that some operations use a (pre-computed) mesh to speed them up. But move or rotate should not be concerned.

I will keep this in the back of my mind if I think of something else.

[tristan-huber]

Ok sounds good. On my end I'll work on collecting more fine-tuned metrics to see if I can identify more specifically what's costing us time.

And of course the resolution may ultimately be for us to just serialize/de-serialize less frequently.