> Yes compared to native langauges all GC languages incur extra IO costs eg > When writing both languages they need to read/copy the data to the kernel , > but the GC language needs to tell the GC to pin each buffer so it doesnt > reloccate it ,this can be significant for lots of small packets.
In the case of Java, it's yes and no. You're assuming a native "java" byte array. Depending on JVM, direct byte buffers are typically allocated off heap and the JVM makes it's "best" effort to perform native I/O operations on it. i.e. avoid pinning and copying to and from underlying buffers. If you are feeling brave, you can use Unsafe to do the same. > GC pauses can be a huge issue... Garbage is a real pain in the ass >Many get around this by storing the message outside the GC This is what the low latency Java guys do -- minimize garbage generation and allocate off heap for predictable latency profiles. > Note pure Java solutions like Java NIO may be better than JeroMQ , there was > a discussion on this earlier . I guess that depends on your definition of better; JeroMQ is a direct port of zmq. If you mean faster (more throughput) JeroMQ will win the throughput race most of the time by utilizing mechanical sympathy like batching to minimizing system calls, etc. > My suggestion, build your real work and use a flexible comms API , use the > easiest comms possible ( which would prob be a a Java lib so you dont worry > about deploying zeromq ) then test the whole end to end process if the comms > is too slow then test zeromq and NIO ( which should be easy since you put > it behind an interface) but not before. Quite frankly, developing real world distributed software is far easier and more fun with zeromq than anything else available that I've tried on the JVM. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
