payetools-steve
payetools-steve

Reputation: 4030

Does ZeroMQ Poll function use excessive CPU on .NET?

I have a simple console application that uses ZeroMQ to send and receive messages. In the receive portion, I have the following message pump code:

   ZMQ.Context _context = new ZMQ.Context(1);

   ZMQ.PollItem[] pollItems = new ZMQ.PollItem[0];

   while (!_finished)
   {
       if (pollItems.Length > 0)
           context.Poll(pollItems, pollTimeout);
       else
           Thread.Sleep(1);

       if (_receiversChanged)
           UpdatePollItems(ref pollItems);
   }

(The idea is that I can add and remove items from the poller at run-time, as I need to add receivers. UpdatePollItems simply creates a new array whenever the set of receivers changes.)

I have tried pollTimeout values of 50ms and 500ms but the app (which is sitting on its main thread on Console.ReadKey) still uses 100% of one core, even when no messages are being sent. I ran the app under the profiler and confirmed that it is ZMQ.Context.Poller that is chewing all the CPU.

Have others seen similar behaviour? I am using the latest ZeroMQ C# binding (clrzmq-x64.2.2.3 from NuGet).

Upvotes: 4

Views: 1822

Answers (2)

Guido Simone
Guido Simone

Reputation: 7952

I'm going to guess that when you say you are setting the poll timeout to 500 ms, that you are setting the variable pollTimeout to 500. Which would be incorrect. For a timeout of 500ms, the variable pollTimeout should be set to 500000. If you do context.Poll(...,500) it is interpreted as 500 usec and it is internally rounded off to 0 ms.

I verified on my own system that passing 500 to poll will cause CPU utilization between 90 and 100%. Setting the value to anything over 1000 makes CPU usage much less and for 500000 (500ms) it should be negligible.

Either way, please update your code sample to the initialization of the variable pollTimeout. If I am completely off base, then at least it will prevent other would-be answerers from going down this path.

Upvotes: 4

mgoetzke
mgoetzke

Reputation: 832

Yes there is a bug in the driver. I hit that as well. Looking at the code it is possible that the .net 4 version should fare better, but you have to recompile it. I will check whether the code I rewrote could be reintegrated as a pull request.

Upvotes: 4

Related Questions