A socket option is a good idea. Is there any way we can abstract this so users don't need to calculate buffer sizes (they will get it wrong often enough)? E.g. _SMALL vs. _FAST?
On Mon, Jul 13, 2015 at 5:29 PM, Auer, Jens <[email protected]> wrote: > Hi, > > > > I ran some benchmarks with the current master to see if the zero-copy > changes have an effect on the performance in my system. As it turns out, in > my setup, the effect is not so large because of the number of malloc calls > still being done. In my setup, I send and receive data streams with up to > 200000 messages per second with a message size of 1125 bytes. The receive > buffer is fixed to 8kb, so I need one allocation for every 7 messages, and > one deallocation. I experimentally increased the size of the receive buffer > to 65kb, and this resulted in a good performance gain, basically trading > memory (which I have lots of) for speed. What is the opinion on a new socket > option to let users set the size of the receive buffer? I think the size > depends on the expected data rate and message size, so it seems fair for > users to be able to influence it. > > > > Best wishes, > > Jens > > > > -- > > Dr. Jens Auer | CGI | Software Engineer > > CGI Deutschland Ltd. & Co. KG > Rheinstraße 95 | 64295 Darmstadt | Germany > > T: +49 6151 36860 154 > > [email protected] > > Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter > de.cgi.com/pflichtangaben. > > > > CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to > CGI Group Inc. and its affiliates may be contained in this message. If you > are not a recipient indicated or intended in this message (or responsible > for delivery of this message to such person), or you think for any reason > that this message may have been addressed to you in error, you may not use > or copy or deliver this message to anyone else. In such case, you should > destroy this message and are asked to notify the sender by reply e-mail. > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
