[zeromq-dev] zmq_poll

[Mark V]

On Sat, May 22, 2010 at 9:11 AM, Serge Aleynikov <serge at aleynikov.org> wrote:
> On 5/21/2010 4:46 PM, Martin Sustrik wrote:
>>
>> The change would simplify the architecture and allow sockets to be
>> migrated between threads (given the proper memory barriers).
>>
>> On the other hand it would have performance impact. Specifically,
>> zmq_poll would be somehow slower as it would have to deal with more fds
>> (one per 0MQ socket). Also, memory consumption would be higher given
>> larger number of open fds.
>  >
>  > Thoughts?
>
> First of all, I think you would only see this performance impact when
> you deal with a very large number of sockets in your application (over
> 100s?), which is likely not the most typical use case.  Secondly, even
> if you have that many sockets, you'll likely still have some
> application-level code that iterates through them when using zmq_poll to
> determine which ones have in/out events.  No?
>

I don't dispute there is a real need, nor that they are important
needs.  Rather I just wonder if this behavior can be added in a way
that if you need it you can pay the penalty, if you don't need it you
don't pay the penalty?

Cheers

> In any case, it's always more reliable to do some proof of concept
> testing rather than doing this comparative guess work regarding
> potential performance impact.  Possibly simplification of architecture
> maybe a good incentive on its own.  It's likely that many 0mq users
> (including myself) are concerned with performance, yet the need for this
> feature is truly not because someone wants to be able to run more
> threads using blocking socket interface, but rather because it would
> allow to decouple 0MQ sockets from the threading model and give a
> developer a chance to use the threading model most suitable for solving
> his/her problem.
>
> BTW, if you are going to spend some time thinking about this, perhaps it
> would be helpful to take a look at specification of socket API of SCTP
> protocol in a way how the concept of a connection is separate from an
> association between endpoints (talking about one-to-many sockets).
>
> Serge
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>