5

I am creating a Firefox extension that allows using Standard ML (SML) as a client-side programming language in Firefox. The way it works is the following:

  1. The extension launches a PolyML process (SML compiler with a top-level interactive shell).
  2. A socket communication is then established between the extension and the PolyML process.
  3. SML code is read from the webpage and is sent via the sockets to the PolyML process for evaluation.
  4. That code may then use a library that I provide, for working with the DOM.

Here is how the DOM library is implemented:

  1. Say someone executes an SML function DOM.getElementById
  2. This request is forwarded via the sockets to the extension, where the extension executes the JavaScript function getElementById on the page and sends the result back to the PolyML process via the sockets.

My question is, in theory, what limits in terms of performance should I be expecting to have here, when it comes to the socket communication?

I did some very approximate profiling and it seems that using this interface between the extension and PolyML, I can approximately send 2500 messages/second, of an average size of 70 bytes/message.

To put this in more context, say I want to draw some animations in the browser using the Canvas element. If I want to achieve 20fps, that means I need to draw every frame in 0.05 seconds, which means I can only send around 125 messages per frame. Those messages correspond to JavaScript function calls. For example, the code below draws a path and is making 9 JavaScript function calls, that correspond to 9 messages in the socket communication.

val _ = Canvas.beginPath context;
val _ = Canvas.setFillStyle context fillColor;
val _ = Canvas.setStrokeStyle context fillColor;
val _ = Canvas.setLineWidth context size;
val _ = Canvas.moveTo context posx posy;
val _ = Canvas.lineTo context posx_new posy_new;
val _ = Canvas.stroke context;
val _ = Canvas.arc context posx_new posy_new (size/2.0) 0.0 6.28 true;
val _ = Canvas.fill context;

JavaScript, obviously, has a much better performance, I would imagine that you could make thousands (hundreds) of times of more Canvas/DOM function calls in those 0.05 seconds, for drawing a frame.

So, I guess my question is, do you have any experience with using socket communication for very rapid message interchange. I would like to know whether 2500 small messages / second (in this case, corresponding to 150 kbytes/second) seems about right or might I be doing something very wrong.

For example, one suspicion is that the socket implementation in firefox (in particular using it via the JavaScript interface https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIServerSocket) is not very good for this kind of rapid interaction. For example, the reading from the socket is done via an event loop mechanism. That is I rely on Firefox.. to notify me about the availability of incoming socket messages and sometimes there is a large (e.g. 250ms) delay between sending the message and receiving it (though that seems to be happening only when firefox is busy with doing other things, and I'm more interested in the ..theoretical.. limits of the socket communication)

Any ideas, any thoughts, any flaws that you see? Do you think using other IPC mechanisms would be better, e.g. pipes, implementing my communication from C++ XPCOM component, rather than from JavaScript, foreign function interface to C (that both JavaScript and PolyML have)?

(The project is located at https://assembla.com/wiki/show/polymlext if anyone's interested)

Sebastian Paaske Tørholm
  • 49,493
  • 11
  • 100
  • 118
Karolis
  • 2,899
  • 2
  • 23
  • 38
  • Are you using TCP? UDP? or UNIX sockets? The latter should be faster as the OS does not have to care about network errors. – bew Feb 22 '12 at 10:12
  • not sure, I was using https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIServerSocket. Do you know if those are TCP, UNIX or configurable? – Karolis Feb 22 '12 at 11:47
  • I also realised that the bottleneck might be JSON encoding/decoding, though I don't remember anymore how much of that was used there. – Karolis Feb 22 '12 at 11:48
  • If I understand the source correctly, nsIServerSocket is always using AF_INET, even for local connections. http://scottmoonen.com/tag/af_inet/ gives a comparison between the two: 100GB transferred in 80.575200 s for AF_UNIX, 100GB transferred in 226.717520 s for AF_INET+loopback. – bew Feb 24 '12 at 10:41
  • IHMO, TCP would be fast enough and would work cross-platform. No UNIX sockets on Windows AFAIK. Your biggest problem is going to be data serialization. – James Mills Oct 30 '12 at 22:45

1 Answers1

1

TCP can be tuned for higher throughput or faster response time. For higher throughput, you need to set the socket buffer to larger value. For getting good response time with smaller chunk of data, you need to set the TCP_NODELAY socket option. TCP on loopback if its fine tuned it should be identical to any IPC mechanism. Newer windows OS does special optimization like increasing MTU size,etc on loopback adapter to make it faster.

dvasanth
  • 1,337
  • 1
  • 9
  • 10