[kea-dev] throughts about footprint

[Stephen Morris]

On 03/09/15 14:14, Francis Dupont wrote:
> These thoughts are supposed to address this action item "Write
> extended coding guidelines that take into consideration the
> memory/binary footprint" (PS: partially (i.e., new ideas are wellcome)
> and of course for decreasing the footprint.
> 
> First idea: maximize sharing. There are some points where something
> can be done:
>  - optimize for space (g++ -Os)
>  - enable link time optimization (great but platform dependent)
>  - instantiate header or mainly header class code: this is required
>   by visibility (which needs something to export) but has an unknown
>   action on a memory size, i.e., it is possible we should optionally
>   extract some class code from headers.
>  - don't abuse of inlining (it seems the current code is reasonable:
>   it relies on the compiler suite to do its best).

I don't know that we are too bad on this but I do think that we could
examine headers and move anything other than trivial one or two-line
methods into the .cc files.

>  - share template instantiation (there is a dedicated feature for
>   this: makes templates "extern": it is a C++ 11 feature but already
>   available by default in many compilers).

We do make heavy use of templates (in particular those in the STL).  As
we don't include the switches "-frepo" or "-fno-implicit-templates" in
our compilations, the implication is that each module using a template
uses its own copy of the template code:

https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

Tackling this would provide a saving in space.

> Second idea: use the visibility feature. This removes unneeded
> relocations (drastic decrease of binary sizes) and helps some
> optimizations.

OK

> Third idea: chase memory leaks. We already use valgrind but they are
> other tools we could try.

We should check for memory leaks, but we rarely - if ever - use "raw"
pointers to allocated memory.  Typically we use smart pointers.

> Forth idea: implement a region class (a la bind 9) which allows to
> share a buffer, for instance a part of a DHCP message. Today the
> only way to extract a part of an input buffer is to allocate some
> space and to copy this part into it. Even a pessimistic evaluation
> of this should win the half of currently used buffer space.

Allied with use of smart pointers, this sounds a promising idea to
investigate.  I believe that we do use this technique in places but I'm
not sure how widespread it is across the code.

Stephen