A blog for developers programming with Autodesk platforms, particularly AutoCAD and Forge. With a special focus on AR/VR and IoT.

December 07, 2009

Asynchronous messages in F# and AutoCAD

I’ve now crossed the international date line (giving up a big portion of my weekend, but that’s life) and landed in Tokyo. Tomorrow I head on to Seoul and then to Beijing for the end of the week. In many ways a change of pace from the week in Vegas, but in other ways it’s more of the same (fun, that is :-).

In this previous post we looked at some code to retrieve and process RSS information from various blogs using an agent-based message passing architecture. The code wasn’t completely asynchronous or parallelised, though, as we fired off each message to start the download synchronously (although the “processing” would have launched quite quickly, yielding control back to the loop which would then launch other downloads). This post shows an even more asynchronous approach, as it fires off the downloads in parallel. We’ll see if it makes much difference. :-)

I executed the four different versions of the commands ten times each and averaged them to get the following results:

Implementation approach (command)

Average time (secs)

Synchronous (RSS)

16.47

Asynchronous (ARSS)

8.45

Message-passing synchronous (MRSS)

15.19

Message-passing asynchronous (AMRSS)

14.14

These values are from when running the code from our Tokyo office: I remember having quite different results when running them from home in Switzerland, for instance. As the network lag here appears larger (probably not helped by the fact I’m connecting via WiFi), the difference is more pronounced which definitely helps us when comparing and contrasting the results.

We see that complexity of this particular problem probably doesn’t merit the overhead of implementing a message-passing approach, although if we do choose to do so the network lag might make it worth the additional overhead of launching the tasks asynchronously rather than one after the other. This balance will shift depending on the local network lag, the processing time and the synchronization overhead: in general doing some kind of benchmark on a simplified version of your problem is likely to be a worthwhile investment before implementing a complete, complex system.