[zeromq-dev] Make zeromq load faster?

David Wolfe evadeflow at gmail.com
Thu Oct 14 18:30:11 CEST 2010


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

It looks like I'm going to be allowed to prototype some new
functionality using zeromq. I'll recount my experiences on this list to
let everyone know how it turns out...


On 10/14/2010 12:03 PM, Martin Lucina wrote:
> Hi David,
>
> dwolfe at fifthsally.com said:
>> Hi, all. I'm looking at zeromq and absolutely loving its simplicity. I'm
>> considering using it in an embedded app because it solves so many
>> problems I would otherwise have to code solutions for by hand.  It's an
>> almost total win.
>
> Great :-)
>
>> There's one problem: though zeromq is 'small' in comparison to any other
>> library aimed at enterprise messaging, it's not exactly tiny from an
>> embedded systems perspective. I've cross-compiled and stripped it for my
>> ARM target and it still weighs in at 301K.
>
> That'd be about right although note that the in-memory size will be
> slightly smaller; if I strip a debug build of libzmq.so on my machine
> (x86_64 Linux) the library is 269K on disk, 256K (.text) + 16K (.bss
> presumably) in memory:
>
> 00007f683c95b000    256K r-x--  /home/mato/src/zeromq2/src/.libs/libzmq.so.0.0.0
> 00007f683cb9a000     16K rw---  /home/mato/src/zeromq2/src/.libs/libzmq.so.0.0.0
>
>> Startup time is a huge concern for the component I'm working on. The
>> mess I'm replacing has the reputation of "loading too slow", and some of
>> my colleagues have decided that it needs to be rewritten in ANSI C to
>> make it load faster. I don't know how they arrived at this conclusion,
>> but it means zeromq's dependency on C++ will be getting a lot of
>> scrutiny.
>>
>> I might be allowed to just try it and see how it works. But if the
>> component still has a startup delay that's deemed "too long", I'm
>> wondering what I can do.  Are there any optional components of zeromq
>> that I can compile out? (I'm only using ZMQ_PUB/SUB and ZMQ_PUSH/PULL
>> sockets.)
>
> 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?
>
> One other thing is at the moment libzmq is not doing the right thing with
> symbol visibility; for a shared libzmq this might cause a small penalty on
> startup due to the dynamic linker busily processing relocations, but we're
> talking really small amounts of time here.
>
> I have a patch for the above in the pipeline, not quite tested extensively
> enough yet...
>
>> I have a feeling that any squashing I can do to zeromq won't put a dent
>> in this, if it's really the culprit:
>>
>> -rwxr-xr-x 1 root root 1.1M 2007-05-09 14:27 libstdc++.so.6.0.8*
>>
>> I don't suppose there's any way to get rid of the dependency on
>> libstdc++? ;-}
>
> libstdc++ provides the C++ / STL runtime, so no.
>
> If you really want to optimize the hell out of it then you could try to
> link everything statically since that'll only pull in the bits of libstdc++
> that you actually need. You'll have to do quite a bit of experimenting with
> the build to make that work right though.
>
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list