[kea-dev] throughts about footprint

Francis Dupont fdupont at isc.org
Thu Sep 3 13:14:58 UTC 2015


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).
 - 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).

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

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

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.

Regards

Francis Dupont <fdupont at isc.org>

PS: most of these points are already in the visibility ticket.
The last 2 are not really coding guidelines...


More information about the kea-dev mailing list