CL often has occasion to listen on TCP ports for process control data. My general advice to clients is that they work in Tcl whenever possible, and that they not fret about performance in particular. While there's no question that C is "closer to the silicon", and is definitely faster for basic bit- and byte-wrangling, Tcl generally is plenty fast.
This page reports on one attempt to quantify that counsel. My model is a client which connects on a port, receives a sequence of bytes, twiddles their bits slightly, and computes a result. Here's the corresponding Tcl code:
proc read_data {} {
set sum 0
set count 0
set mask 0x5A
set channel [socket localhost 5837]
while 1 {
set data [read $channel]
foreach item [split $data {}] {
incr count
set value [scan $item %c]
set addend [expr ($mask & $value) >> 1]
incr sum $addend
# puts -nonewline "$value ($addend) "
}
if [eof $channel] break
break
}
puts "\nSum is '[format %x $sum]'."
return $count
}
set result [time {set count [read_data]} 3]
puts $result
# This is a hackish way to extract the time.
set microseconds [lindex $result 0]
set quotient [expr round(double($microseconds) / $count)]
puts "$quotient microseconds per byte received."
On a generic Linux x86 host at hand, when I blasted random data from a simple server (see below) as fast as possible, I observed these results:
simple Tcl client simple C client
100 bytes 32 microseconds per byte received 36
300 25 14
1000 20 6
10000 19 2
30000 19 2
100000 22 2 My summary: unless message sizes are quite large, or you're willing to tune your C coding carefully, write in Tcl, and safely assume that the performance penalty is 90% at most (an amount easily lost in network, UI, and other noise), and possibly far less.
See also "Tcl socket performance", "Socket performance analysis", "How to measure performance", and the rest of Category Performance.