I have recently had occaision to test Tcl sockets performance across Gigabit Ethernet links between fairly modern machines (i.e. P IIIs at 700 and 900 Mhz, XEONs at 1 GHz). the following observations devolve from these tests:
Special test codes (not real world), are reported to be able to achieve about 60 MBytes/sec across these links. So Tcl sockets appear capable of something like 40 % of link capacity, while a C application can do about 83 % of capacity. Tcl is half the speed of a C application.
It appears the Windows 2000 sockets and Tcl sockets are, as a couple, not happily married. It is easy to crash a Windows based Tcl script that uses sockets, apperantly because of a decision by Microsoft to ignore buffer sizes in its socket implementation. This problem is NOT manifest on W95/W98 which run the tests reliably.
Performance over 10BaseT links
On a 10BaseT link, Tcl sockets will run at about 65% of link capacity. The equivalent script running on Linux boxes will achieve 96% of link capacity.
The test environment here is Tcl 8.3.2 on all machines, W98 on the windows box and RH 7.0 and Slackware 96 on the linux boxes. Surprisingly, the test used a rather old 166 Mhz P II box running Slackware. CPU speed is clearly not a factor in these 10 Base T tests. This is also confirmed by some other tests on the GigaBit links that showed that increased CPU speed could result in LOWER link performance.
It is currently thought that this result is due to other factors than CPU, such as the brand of interface card used, the card driver, or some other environmental factor.
Here are the scripts used for the tests:
Speed-up sockets on the NT platforms with iocpsock. I think the results are impressive, especially when running a server. iocpsock can get 100% usage on 100mbps ethernet, which can possibly beat non-optimized 'C' [ie. use of select() or WSAAsyncSelect()] ;) -- DG
DG: It could even be more efficient if fcopy could Tcl_GetDriverHandle than use TransmitFile bypassing Tcl altogether. Use of fcopy doesn't fix the current winsock driver as winsock itself is getting over-run, thus making Tcl look to be at fault when in fact garbage in == garbage out.