Topic: Optional std::array backend on int/float-array/matrices
I'm just dumping some ideas here, which might interest others. I'm not in any planning phase, and I have plenty of more important things to start with, but;
We have a fair few methods that construct could really benefit from stack allocation.
Naturally, we do need the dynamical size of the heap in many places if we wish to keep the virtual method calls everywhere (in order to cater to elements of all shapes and sizes), but on those places, copying the data would be so cheap I think it's easily worth it.
A few places where I think it would make a difference;
FEInterpolation :: evaldndX - For each implementation all the sizes are hardcoded anyway, only the input/output would need to be the stack allocations.
Node :: coordinates - Hardcoded 3D would and let 2D code just pad out with 0s would save on total memory and remove one indirection == much fewer cache misses on a *very* hot code
MaterialStatus* :: internal state variables - A fixed size (6) for the stress would in almost all cases both save memory and reduce cache misses, and make implementations easier. Same applies to all other internal variables that fit into S3, S3E, etc.
Before diggin into this, one needs to consider;
1. There can absolutely be no virtual method calls here, as they are very very expensive and would kill performance in critical code.
2. Do we template all of our FloatArray/etc. code and instanciate 2 versions (std::vector backend, FloatArray, and a std::array backend FloatArray<N>)
3. Do we look at other libraries that have already done all of this?
2 vs 3 is a tough one, and I can think of reasons for either approach. We need to be able to add specializations for all of our important methods if we go for 3, but there are really good libraries out there.