On 04/02/2012, at 9:53 PM, Pieter Hintjens wrote: > On Sat, Feb 4, 2012 at 1:26 AM, john skaller > <[email protected]> wrote: > >> Someone else in the community concerned with performance no doubt has >> some test code which performs measurements. Such code would be more >> reliable than anything I could write. > > What I would do, would be to take the current performance test > programs (latency and throughput tests) and create versions that use > locked sockets. These are pretty effective tools for measuring raw 0MQ > performance, if you run local and remote on the same multicore box.
I can have a look at that, however the issue here isn't the performance of locked sockets, but performance of the old code vs. the new code *not using* the new feature: the real issue is how much non-users of the locking feature will pay. This is a bit trickier to check (I need two versions of 0MQ to do it) The actual cost of using locked sockets has to be compared with the cost of "doing it the old 0MQ way" using multi-plexing intermediaries as outlined by Chuck previously. The comparison is not just performance but also LOC and how easy each is to maintain. -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
