Open ndemou opened 1 year ago
Following my observation that ReceiveBytes
always takes 500msec when no data are waiting I had a bit more time to fiddle around and found an apparently safe tweak that can help to drop the minimum response time of a dummy echo server from 515 to 15msec. If the developer(s) have time and care about performance, I would love to hear if my assumption in bold below is correct.
The tweak is to change the value 500 in line timeout = 500
that appears in TcpClient.cls
. In my case (working on a gigabit LAN that has a typical 0msec ping) I set it to 10 and it seems to work perfectly. On a link with 50msec RTT I would have set it to 60 (i.e. RTT in msec+10).
As far as I can tell this value is the maximum time in milliseconds that ReceiveBytes
will wait for bytes to be received from a client.
Hi, I was experimenting with the performance of this library and I noticed that I can drop the response time from ~500msec to ~15msec by making a simple change (which however is probably buggy for special cases). It may be a hack but if someone wants to get more juice from this library it may point to the best point of the code to look at.
Specifically in function
ReceiveString()
I changedLoop While Len(buffer) > 0
toLoop While Len(buffer) = 1024
More details
This is the code of the function (without the variable Dims)
As far as I can tell with
Loop While Len(buffer) > 0
you always do an extra call toReceiveBytes(1024)
which it seems always times out after ~500msec if there are no more bytes from the client. This call is 99.9% of the time unneeded and that is why my tweak has the effect it has. I guess that 0.1% of the time my tweak will result in missing a part of the client request (specifically if the client sends 1024 bytes or 2048 bytes in two parts etc).Is there any way we can make
ReceiveBytes(1024)
return fast if there are no bytes waiting?