[zeromq-dev] Make zeromq load faster?

[Marcelo Cantos]

On 15 October 2010 03:30, David Wolfe <evadeflow at gmail.com> wrote:

> > No, not really. Having said that, why would the on-disk image size
> > impact startup time so much? Are you using slow flash to boot from or
> > something?
>
> This is the same question I keep asking myself. I have a lot of
> experience with realtime apps on 'industrial PCs', but I've only
> recently started working with truly embedded systems. My
> colleagues---who have decades of experience in this space---feel that
> starting a C++ app from a cold boot will be noticeably slower than
> cold-booting into a C app.  I have to defer to them on this.
>

This is a common fallacy, but it is built around a few nuggets of truth that
one must be wary of when using C++ in embedded systems.

Firstly, C++ provides the ability to run user code before main() is called
via the instantiation of static variables who's classes have non-trivial
constructors. In some scenarios, this static initialisation can take
inordinate amounts of time, since poorly-written libraries may statically
initialise many objects that never get used. In practice, however, this is
almost never an issue, since most libraries are quite sparing in their use
of static initialisers, with many going as far as loading all static objects
on-demand (which is actually quite easy to do in C++).

Another nugget is that, historically, C++ compiler authors have had their
hands full implementing the entire breadth of an extremely complex
programming language, and have thus neglected other aspects such as
optimisation, code size, etc. Since embedded systems programmers would have
suffered the most from these deficiencies, they have probably all developed
a sense of dread at the thought of unleashing C++ code on their hapless
power-and-memory-starved boards. Depending on the compilers you are using
this may or may not still be the case, but it is largely a non-issue for
modern compilers.

The final nugget that comes to mind is that exception-handling may introduce
a small cost to the runtime, usually around 5-10% (my memory of this is
quite old, and may be completely out of date). If this cost is unacceptable
and none of your code or libraries uses exception handling, most compilers
will let you turn it off. As far as I can tell, ZeroMQ's C++ binding throws
exceptions, but its implementation doesn't use them at all, so you should be
able to use ZeroMQ's C binding with exceptions turned off. You may then also
be able to save space by turning off RTTI, which is usually only needed for
exception-handling.

Other than that, C and C++ load times should be practically identical. You
can confirm this by recompiling your C app as C++ (which will probably
highlight a ton of spurious coding practice and even real bugs, before you
get everything successfully linked), making sure exception-handling and RTTI
are both off, and comparing the resulting binary to the C build.

Of course, you should take all the above advice with a grain of salt. As
Pieter advises, don't assume, test.


Cheers,
Marcelo

P.S.: The situation with exception-handling is more complicated than the
above comments suggest. There are two key implementation techniques used by
C++ compilers: code and tables. The code technique injects hidden parameters
and exception-checking code at most function-call sites, which incurs the
5-10% penalty I discuss above. The table technique emits static tables that
allow the exception throwing mechanism to unroll the stack and search for a
matching catch block without the assistance of hidden parameters. In systems
with virtual memory, this has almost no cost until the first time an
exception is thrown, and may then incur a massive hit due to the need to
page the tables in from disk. On embedded hardware without virtual memory,
the size of the tables will be a (possibly major) concern up-front.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101015/6516e4e3/attachment.htm>