Memory usage skyrocketed since moving to header-only

[wxmerkt]

Since moving to header-only in #695, the memory usage during compilation sky-rocketed:

Is there any way to use precompiled headers or something to make it more manageable?

[proyan]

Some of it is expected. How many threads are you using for compilation?

[wxmerkt]

12 threads/full CPU by default but it exceeds 16GB with/after 3 threads. I am aware it's expected but is there a way to reduce it though?

[proyan]

I think we can be a bit smarter when including headers. This would be the first step. But I don't think I can handle it immediately, it would have to wait atleast till next week.

[cmastalli]

The memory could be reduced it by splitting the implementation of a classe. Let's say for the DifferentialActionModelContactFwdDynamcs class, we have

1. contact-fwddyns-calc.hpp and contact-fwddyns-calcdiff.hpp
2. contact-fwddyns-calc.cpp and contact-fwddyns-calcdiff.cpp

This could be done for few classes that are needed (such contact and impulses differential action models) @nim65s is a good practice to do this?

[nim65s]

It's easier to compile many smaller .o and link them later in a big .so, yes.

Smaller source files comes with a better readability, a more granular recompilation and caching, and easier merges.

[cmastalli]

@nim65s thanks for the answer

@wxmerkt could you let me know which classes are memory hungry? Let's figure out a plan of attack for this issue.

[wxmerkt]

The most memory hungry were free-fwd-dyn.hxx and contact-fwd-dyn.hxx. You can measure before/after using /usr/bin/time -v make -j1

[proyan]

@cmastalli are you taking care of this?

[cmastalli]

I'm not working on it now.

If you decide to work on it, then assign this issue to you. I'll do the same.

[cmastalli]

@proyan I won't work on this task. This task is not near to be priority for me. I am imposing myself to follow the rule if it ain't broke don't fix it since I can't spend my time on these activities.

If someone doesn't offer his/her help within a week, then I would close this issue. It is not useful to keep issues that are not going to be handle.

Does somebody disagree?

[wxmerkt]

We should keep the issue open. Issues should only be closed if they are resolved. This issue is a real problem unless you have 64GB RAM.

[wxmerkt]

I've noticed a further spike in compilation time (to ~35mins with Python bindings, examples, no unit tests) and memory usage for devel recently (from perhaps December to now): Using 12 threads, I now commonly exceed 64 GB memory with another 17 GB swapped during peak:

This is using a i7-9850H (all cores in boost at 3.96 GHz, 12 MB cache). Are you seeing similar times or resource use? Is there something we can do about this?

[proyan]

I don't have the consumption that you have, with Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz, and 8MB L3 Cache. I peak out at 20GB with 8 cores. Memory is definitely a problem, and there are some obvious solutions to this (as @nim65s pointed out). But the problem right now is the available manpower behind this issue. Unfortunately, I think for most of us this is low on priority.

Are there any simple fixes we can make to improve this, which don't require big refactoring of the code?

[jcarpent]

Don't use gcc but llvm/clang instead ;)

[cmastalli]

@wmwrkt and @proyan -- could you report the compilation performance with clang (as suggested by @jcarpent)?

[wxmerkt]

From periodic visual inspection, memory usage topped out at ~32GB. The compilation finished in 12min49s which is considerably less than the ~35mins with gcc. Thanks for the suggestion @jcarpent :-).

[proyan]

The perf I specified is with clang, so @jcarpent's suggestion checks out :)