Hi Norbert. Big thank's for feedback.

I commit new version of Seamless with compressed protocol (by gzip). Not big change but results are better. I see ~25% improvements.

Here is statistics of my Seaside demo with "gziped" fuel protocol (it is default now):

- 3 kb to connect debugger

- 100 kb for opening debugger preview.

- 100 kb for full debugger

- 60 kb for selecting another context.

- 868 bytes to evaluate ��"[1+2]" (with returned result).

I improved logging in this version to collect "bytes statistics". You can analyze communication by starting SeamlessLogger and collecting statistics when you are ready:

SeamlessLogger startAfresh. "to clear old history if exists"
SeamlessLogger collectStatistics. "inspect it when you are ready to look at what was happen"��

Here is what you will see for debugger connecting:

��

2016-07-18 19:11 GMT+02:00 Norbert Hartl <norbert@hartl.name>:

Ok, I experimented a bit with network qualities. I just tested connecting and executing 3 + 4 on the remote side.�� Connecting transfers already 2-4kb of data which should add some latency when the network is bad. Local wifi and DSL connections work ok for the simple case because latencies are low.

On a 3G network it can take between 4 and 7 seconds to establish the connection and around half a second to execute 3 + 4. I defined a bad mobile network with 20kb/s bandwidth, 10% packet loss and a delay of 100ms in transmitting. This is equally for down and up directions. The connection time raises to 11 seconds and the execution of 3 + 4 to 4 seconds.��

In order to be able to test I needed to tweak BasysNetwork>>#initialize to set a timeout greater than 45 milliseconds which is pretty low. Usual timeout settings for browsers and mobile applications are around 30 seconds. I raised it to 10 seconds in order to test the bad network.��

To me the results are more or less expected. Well, I hoped they would be much better :) It works reliably even over slow networks. The main problem is that when it comes to remote debugging environments or browsers the number of message sends is quite high. So it is to see what kind of environment these tools can serve. For sure there is plenty of space to optimize (I hope). I did the tests with bad/mobile networks just get a clear mark where it cannot be used. To me personally the benchmark is DSL upload speeds. If it is doable over these (could be 256k/s) I can connect from the office (DSL down) ��the my little devices at home (DSL up) ��;)��

I see big room for optimizations here.��

Look at very small unit of communication: delivering integer result (from [1+2] evaluation). Following object is responsible for this:

request := SeamlessDeliverResultRequest result: (SeamlessReturnValueResult with: 3) to: (SeamlessRequestContextReference id: 4 peerId: UUID new) .
stream := ByteArray new writeStream.
FLSerializer newDefault serialize: request on: stream.
bytes := stream contents.
bytes size. "==> 412"
(ObjectTraveler on: request ) countReferences ��"==>10"

��

Last line shows that only 10 objects consists full object graph of request. And Fuel serialization takes for it 412 bytes.

It definitely could be improved with specialized serialization protocol. Also it could allow object traversal once which will lead to another performance improvements.