c++ - On RCF Middleware Binary Size -

rcf library/framework rpc , distributed messaging. rcf framework following reasons

1. in line service - interface - rpc call specification (i.e., no separate compilation of idl).
2. c10k design style (layers ontop of windows iocp or boost asio).
3. supports windows named pipes , unix domain sockets (i absolutely cannot compromise on this).
4. ssl.
5. messaging paradigms, 2-way, 1-way, client-callback, 1-way batched.
6. protocol buffers support (tho think can stick built-in-serialization).
7. publish/subscribe functionality.

i using gcc 4.4.3 on 64-bit ubuntu install. compile trivial server , client code using following line in demo subdirectory of distribution.

g++ -o3 -drcf_use_boost_asio client.cpp ../src/rcf/rcf.cpp -i ../../boost/ -i ../include/ -lpthread ../../boost/lib/libboost_system.a -s

the resulting client , server binaries fluctuate between 1.7 2.2 megabytes.

alarm bells ringing; use following 3 examples yard sticks:

1. boost::asio: server 2 example compiled in release version using bjam. resulting code , stripped, 176kb.
2. nginx: highly complex, configureable, efficient web-server. 500kb stripped.
3. trandsport channel focused minimal middleware solution 0 mq. libzmq 274k

i have written own production rpc/middleware , i'm getting stage i'm thinking i'll write 1 meet needs, layering on top of boost. not want this. rcf's design, meets needs. however, can't justify binary size of simple programs, should not produce such massive binaries.

i have 2 main concerns.

1. the quality of code-paths rpc. want low latency.
2. the growth of binary start coding application arround it.

a reasonable explanation library isn't designed modularity, , instantiates upfront.

["the question"]

i'd feedback folks design real-time data-processing systems on concerns. justify size ?

["/the question"]

i'd consider alternatives. zmq nice, aditional dependancy, misses ssl, doesn't provide lot of middleware primitives, , doesn't provide named pipes (i need verify connecting processes, , named pipes have security contexts)

what command line doing, compiling rcf statically server , client executables. makes build process simple, means both executables carrying around own copy of rcf. there on 60000 lines of code in rcf 1.3, have impact on executable size.

you can build rcf dll, , link instead. you'll need define rcf_build_dll when building dll, or nothing exported.

for ballpark figure, on visual c++ 2008 build environment have, results in 1.6 mb dll. there still code ends in importing module, rcf's marshaling code uses templates , templated code needs inlined in headers, can't exported dll.

on concerns:

(1) rcf designed start low-latency in mind, , critical path remote call highly optimized. there no memory allocations @ instance, , no copying of message data. if you're worried, can write simple client , server , see how many thousands of calls can make per second (just remember use release build). more information, have @ performance section in user guide

(2) library, there front size overhead when build application. there won't 'ongoing' overhead after that.