[zeromq-dev] Profiling and 0mq

hp010170 hp010170 at gmail.com
Sun Jun 17 15:41:58 CEST 2012


Am I right to assume that the silence over a week means no specific or 
significant interest in getting profiling to work in the supplied 
performance tests?

On 14/06/2012 11:29, hp010170 wrote:
> I was just wondering if someone had come across this lately; as I have
> been trying to run the GNU profiling/coverage tools and also the Google
> Performance Tools (gperftools), but both seem to yield the same problem:
>
> The library was built from master using
> ./configure --with-gcov=yes CXXFLAGS='-pg' CFLAGS='-pg'
>
> --xx--
> hp$ ./perf/inproc_lat 10 1000000
> message size: 10 [B]
> roundtrip count: 1000000
> error in zmq_recvmsg: Interrupted system call
>
> hp$ ./perf/inproc_lat 20 10000
> message size: 20 [B]
> roundtrip count: 10000
> average latency: 39.693 [us]
>
> hp$ ./perf/inproc_thr 20 100000
> message size: 20 [B]
> message count: 100000
> error in zmq_recvmsg: Interrupted system call
>
> hp$ ./perf/inproc_thr 20 10000
> message size: 20 [B]
> message count: 10000
> mean throughput: 101855 [msg/s]
> mean throughput: 16.297 [Mb/s]
> --xx--
>
> Clearly that's happening because of EINTR not being handled in the
> (performance) tests, dependant upon profiling granularity.
>
> The 6 million dollar questions being:
>
> 1. Should they be handled in the perf/*.cpp files to set an example and
> consequently make profiling work out of the box?
> 2. Am I barking up the wrong tree?
>
> In case of [1], as you may know in REQ/REP examples, it is not just a
> matter of retrying, since that returns EFSM due to the strict
> alternating pattern; unless I have read the manual pages incorrectly.
>
> I would appreciate if people familiar in the relevant dark arts can shed
> some light on this matter.
>
> -HP
>





More information about the zeromq-dev mailing list