[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