Fix big-ish memory leaks when not actually using/accessing Mantaflow
Julian Eisel
Branch: julianeisel/manta:fix-memleaks
julianeisel/manta:fix-memleaks
Branch: mantaflow/manta:master
mantaflow/manta:master
Open
#5 · Created  · Last updated
Description
E.g. just opening and closing Blender would cause Mantaflow memory leaks of >100KB.
Cause is static variable construction which call the WrapperRegistry constructor (adding default classes) and add own classes, methods, etc. If the application does not call Pb::finalize() - which you’d typically only do if Mantaflow is actually used - this memory leaks.
For example, shapes.h.reg.cpp does such static constructions:
There really should not be so much static member construction going on at startup. It slows down application startup time and allocates quite some memory - high costs for a feature that may not even be used. I’d even go as far as considering this a bad code smell
A simple way to refactor this would be moving the currently static members into a separate data structure as non-static members. This should be lazy initialized (only construct once Mantaflow is explicitly constructed by the application). If static access is really needed, there could still be a static (global) pointer to it.
E.g. just opening and closing Blender would cause Mantaflow memory leaks of >100KB.
Cause is static variable construction which call the
WrapperRegistryconstructor (adding default classes) and add own classes, methods, etc. If the application does not callPb::finalize()- which you’d typically only do if Mantaflow is actually used - this memory leaks.For example,
shapes.h.reg.cppdoes such static constructions:static const Pb::Register _R_12("Box", "Box", "Shape"); template<> const char *Namify<Box>::S = "Box"; static const Pb::Register _R_13("Box", "Box", Box::_W_9);If I may give a bit of design feedback:
There really should not be so much static member construction going on at startup. It slows down application startup time and allocates quite some memory - high costs for a feature that may not even be used. I’d even go as far as considering this a bad code smell
A simple way to refactor this would be moving the currently static members into a separate data structure as non-static members. This should be lazy initialized (only construct once Mantaflow is explicitly constructed by the application).
If static access is really needed, there could still be a static (global) pointer to it.