search

uludaggonul / snow-dots

Automatically exported from code.google.com/p/snow-dots
0 stars 0 forks source link

profile transactions #54

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Please find detailed timing of transaction overhead

Original issue reported on code.google.com by joshiang...@gmail.com on 18 Oct 2010 at 6:13

GoogleCodeExporter commented 8 years ago 
In version 1.0, transactions will be handled by a "remote bridge" class.  This 
class can invoke the Matlab profiler around its transaction methods in order to 
gather information about overhead.

Original comment by Benjamin.Heasly on 8 Jan 2012 at 10:13

GoogleCodeExporter commented 8 years ago 
As of r824, I've reduced transaction overhead significantly.  In rough numbers, 
on my MacBook, using the loopback IP address, transactions that were taking 
about 5ms now take about 2-3ms.  There were two big sources of overhead:

  * dotsTheMessenger.waitForMessageAtSocket() was using m-code to poll for messages.  This was useful for remote object manager singletons that needed to do behaviors concurrently with polling.  But the new dotsClientEnsemble class (the "remote bridge" referenced above) doesn't need to do this.  So I was able to eliminate waitForMessageAtSocket() and with it a lot of m-function calls.
  * dotsAllSocketObjects now allows check() to block for an interval until a message arrives.  This allows the socket implementation and the OS to handle the polling, which is more efficient than polling in m-code.  This allows Snow Dots to respond faster once an expected message to arrives.

dotsClientEnsemble can invoke the profiler around its messaging calls, too.

So I'm closing this issue.

Original comment by Benjamin.Heasly on 5 Mar 2012 at 4:31