[zeromq-dev] migration 4.1.2 to 4.2.2

brunobodin . brunobodin at gmail.com
Mon Mar 13 13:45:42 CET 2017


So I am probably paying the cost of not having your PR.

BB

On Mon, Mar 13, 2017 at 11:19 AM, Doron Somech <somdoron at gmail.com> wrote:

> Yes.
>
> Also, consider using the wait_all, which should yield better performance.
>
> On Mar 13, 2017 10:13 AM, "brunobodin ." <brunobodin at gmail.com> wrote:
>
>> Hi Doron
>>
>> In my test, the timers are not supposed to include the poller creation
>> time. To be sure, I increased the iteration count, but the result stay the
>> same (10% increase or so). This run does not include your PR.
>> Does this PR apply to both the new and old APIs ?
>>
>> Bruno
>>
>> On Sat, Mar 11, 2017 at 10:03 AM, Doron Somech <somdoron at gmail.com>
>> wrote:
>>
>>> Following is a PR that fix the slow performance of zmq_poll
>>>
>>> https://github.com/zeromq/libzmq/pull/2364
>>>
>>>
>>>
>>> On Fri, Mar 10, 2017 at 6:30 PM, Doron Somech <somdoron at gmail.com>
>>> wrote:
>>>
>>>> How many iterations in the test? The creation of the zmq poller might
>>>> slow you down a bit at the begining...
>>>>
>>>> On Mar 10, 2017 6:16 PM, "brunobodin ." <brunobodin at gmail.com> wrote:
>>>>
>>>>> Thanks Doron for the explanation
>>>>>
>>>>> I replaced zmq_poll calls in my code, the new API is also easier to
>>>>> use IMHO :-)
>>>>> but FYI, I still notice a slight slowdown in my test (about 10%), but
>>>>> this is far from a unit test so I am not sure this is related to the new
>>>>> poller
>>>>>
>>>>> Bruno
>>>>>
>>>>> On Fri, Mar 10, 2017 at 5:01 PM, Doron Somech <somdoron at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Not sure, the change only introduced and recent version,  I think. I
>>>>>> will make a pull request tomorrow and you will be able to test it.
>>>>>>
>>>>>> On Mar 10, 2017 5:43 PM, "Jake" <jake.cobb at gmail.com> wrote:
>>>>>>
>>>>>>> Do you all think this is related to the Windows performance issue I
>>>>>>> reported here?:
>>>>>>>
>>>>>>> https://github.com/zeromq/libzmq/issues/2328
>>>>>>>
>>>>>>> -Jake
>>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 10:36 AM, Doron Somech <somdoron at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> zmq_poll now use zmq_poller internally, but nof efficiently,
>>>>>>>> because it is being created on every call. This is why you have drop in
>>>>>>>> performance, I will fix that anyway.
>>>>>>>>
>>>>>>>> Polling on thread safe sockets works differently, this is why zmp
>>>>>>>> poller was created. previously zmp poll didnt support thread safe sockets.
>>>>>>>>
>>>>>>>> Bottom line, zmq poll should be deprecated and zmq poller should be
>>>>>>>> used.
>>>>>>>>
>>>>>>>> On Mar 10, 2017 3:13 PM, "brunobodin ." <brunobodin at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Doron,
>>>>>>>>>
>>>>>>>>> I could make a test and it works, thanks !
>>>>>>>>> is the signaler new in zmq 4.2.2 ? if not, why are the
>>>>>>>>> performances so différent ?
>>>>>>>>>
>>>>>>>>> Regarding thread safe socket, I do not use them yet but may test
>>>>>>>>> them (probably RADIO/DISH) in a near future. Are there implications between
>>>>>>>>> poller and thread safe sockets ?
>>>>>>>>>
>>>>>>>>> thanks for your help
>>>>>>>>>
>>>>>>>>> Bruno
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 1:26 PM, Doron Somech <somdoron at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> If you can use zmq_poller it will solve it.
>>>>>>>>>>
>>>>>>>>>> I can make a PR to improve it by making tge creation of the
>>>>>>>>>> signaler lazy.
>>>>>>>>>>
>>>>>>>>>> Are you using thread safe sockets (SERVER CLIENT ...)
>>>>>>>>>>
>>>>>>>>>> On Mar 10, 2017 13:01, "brunobodin ." <brunobodin at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all
>>>>>>>>>>>
>>>>>>>>>>> digging deeper, the issue seems related to the connect/bind of
>>>>>>>>>>> signaler within the poll function.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 8:46 AM, brunobodin . <
>>>>>>>>>>> brunobodin at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Luca,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks for you anwser... apparently select is the only method
>>>>>>>>>>>> available on windows, and is the one used by the appveyor build.
>>>>>>>>>>>> Draft is not enabled.
>>>>>>>>>>>>
>>>>>>>>>>>> still investigating...
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> Bruno
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 9, 2017 at 6:12 PM, Luca Boccassi <
>>>>>>>>>>>> luca.boccassi at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 2017-03-09 at 17:22 +0100, brunobodin . wrote:
>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I am in the process of migrating my application (windows,
>>>>>>>>>>>>> visual 2015) from
>>>>>>>>>>>>> > 4.1.2 to 4.2.2
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > The point is that with the new version, polling is now
>>>>>>>>>>>>> _very_ slow, making
>>>>>>>>>>>>> > my app quite unusable.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Any hint or suggestion about what I could check ? The
>>>>>>>>>>>>> polling method is
>>>>>>>>>>>>> > "select", optimization options of the compiler are set, the
>>>>>>>>>>>>> performances of
>>>>>>>>>>>>> > the performance tools (inproc_lat, etc) are ok...
>>>>>>>>>>>>> > I do not know what to look for next...
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > thanks
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Bruno
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where you using select before as well?
>>>>>>>>>>>>> Are you by any chance building with the DRAFT APIs enabled?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>> Luca Boccassi
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> zeromq-dev mailing list
>>>>>>>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>>>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> zeromq-dev mailing list
>>>>>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> zeromq-dev mailing list
>>>>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> zeromq-dev mailing list
>>>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> zeromq-dev mailing list
>>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> zeromq-dev mailing list
>>>>>>> zeromq-dev at lists.zeromq.org
>>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> zeromq-dev mailing list
>>>>>> zeromq-dev at lists.zeromq.org
>>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170313/f0fc1733/attachment.htm>


More information about the zeromq-dev mailing list