To find the answer to this question I put together a very simple test, but before we go into it..

Disclaimer: this test and its result should be taken at face value only, it is intended to illustrate that posting messages to an agent is super lightweight, but in a real world application there will be many other constraints and considerations (such as latency, etc.) that should be taken into account before you decide to use F# agent instead of other alternatives.

So, back to the test itself, here’s the test code:

the line that posts 30 million messages (4 byte integers in this case) to the agent returned in 0.983 second, but the agent actually took just over 12 seconds to receive and process all the messages.

Suffice to say that in most cases trying to get messages to a F# agent is unlikely to be the bottleneck in your system at a solid 30 million messages a second

However, processing of those messages takes significantly longer, and if the backlog continues to build then eventually you will be hit with an OutOfMemoryException. Also, if you’re depending on a sync/async reply from the agent, latency can also be a big problem if the agent is allowed to build up a huge backlog of messages. Keep these in mind when you’re designing your application around F#’s agents.

Finally, for the question of ‘how many messages can you post to a F# agent in one second?’, on my Corei7 3.3GHz, the answer is a cool 30 million

As for the results, on my test runs, it seems that, in this benchmark, Hopac’s synchronous message passing primitives achieve up to about 6x better throughput. Also, Hopac’s asynchronous Mailbox primitive, which supports asynchronous message passing, seems to achieve, at peak, slightly better posting performance and about 5x better throughput than MailboxProcessor.

theburningmonk • Author

@Vesa – that’s amazing! It’s so good to see you and Anton bringing over your expertise from CML to the .Net world, I’ll check it out and let you know if I run into any problems. We have quite a few components and libraries in our stack which depend upon the F# mailbox abstraction, so it’d be of great interest to us to be able to significantly improve upon its performance.

Do you plan to release Hopac as a nuget package?

Vesa Karvonen •

Thanks! Do note that Anton is not responsible for any potential problems in Hopac. :)

I do plan to release Hopac as a NuGet package, but there are still a couple of things, including both documentation and a couple of implementation issues, I want to do on the library before first release. It will probably take a week or two before first release depending on how much time I can put into working on the library.

It would be great to get feedback on potential problems when trying to use Hopac. The actually application I’m using Hopac for was structured with Hopac in mind. If you have an existing architecture using MailboxProcessors and Asyncs, then it probably won’t be as simple as replacing them with Hopac’s Mailboxes or Chs and Jobs, because there are some deeper differences between those. But I’m definitely looking forward to hearing about potential problems you might encounter. If you have any questions don’t hesitate to ask me.

theburningmonk • Author

@Vesa – thanks for the heads up, look forward to when the project hits Nuget. I had a look at the project last night and as you said, the abstractions offered by Hopac is quite different from the MailboxProcessor and will probably take a bit of work to adapt into our existing solutions, but the potentials are quite exciting and we’ll definitely try it out once our iPad launch is out of the way. I’m sure I will have plenty of questions for you when the time comes ;-)

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.