[zeromq-dev] Very Small Messages/Manual

[Martin Sustrik]

Matt,

Yes, there should be a guide to compile-time performance tuning of 0MQ. 
The question is what percentage of users has enough theoretical 
background, experience, available HW resources and funding to perform 
relevant benchmarking and tuning.

Existing compile time constants are carefully chosen to perform best on 
common modern hardware. Playing with them is likely to cause more harm 
than good.

Thus, describing the compile-time constants without explaining 
benchmarking/tuning methodology, trade-offs to make etc. is kind of 
pointless.

Once I've written an article about measuring jitter:

http://www.zeromq.org/whitepapers:measuring-jitter

Articles about measuring throughput and latency are still missing at the 
moment :(

Martin

Matt Weinstein wrote:
> Perhaps there should be a section entitled e.g. " Optimizing ZMQ "  
> somewhere in the online documentation...
> 
> For example, you *could* tweak the VSM size (according to zmq.h) for  
> certain applications and architectures --
> 
> /*  Maximal size of "Very Small Message". VSMs are passed by  
> value            */
> /*  to avoid excessive memory allocation/ 
> deallocation.                        */
> /*  If VMSs larger than 255 bytes are required, type of  
> 'vsm_size'            */
> /*  field in zmq_msg_t structure should be modified  
> accordingly.              */
> #define ZMQ_MAX_VSM_SIZE 30
> 
> On Jul 24, 2010, at 10:57 AM, Martin Sustrik wrote:
> 
>> Oliver Smith wrote:
>>> Martin Sustrik wrote:
>>>> Messages below 30 bytes of
>>>> length are called VSMs (very small messages) in 0MQ and are passed
>>>> *without* any extra memory allocations.
>>> Actually, this is a fairly important/useful piece of information.  
>>> Can I
>>> suggest that it be added to the main zmq.html of the manual under the
>>> Messages heading?
>> Hm. It's kind of an implementation detail. Our tests have shown that  
>> for
>> messages below 30 bytes copying them is less expensive than
>> allocating/deallocating a chunk for the data. As everything stays  
>> opaque
>> for the users, I am not sure why they would be interested in that kind
>> of detail.
>>
>> Martin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev