I personally think that might depend on what you mean by "slow". Tcl/Tk programs can be very light and memory-efficient -- you can pack a lot of features into a program that only takes 10 megabytes or less at runtime and that starts up and responds to input near-instantly. The event loop abstraction which is well-integrated in Tcl makes it easy to handle sockets, files, timers, and gui events all on one loop which done right can keep your program very responsive without needing to worry about multithreading.
In terms of pure runtime performance (CPU efficiency I guess), do you know of any reasonable benchmarks comparing TCL to say, Python and Ruby? I wonder if they might all be in the same ballpark?
We were a startup with our own webstack, similar to AOLServer.
It was a great experience and we had quite a few in-house tooling that I only saw years later in Rails.
Those issues lead us to become early .NET adopters as Microsoft was searching partners for getting their products ready to ship when .NET 1.0 would be announced to the world.
Since then I only use scripting languages for shell scripting.
Years ago, I had to port a tcl/tk ui to java swing. I had source code to copy off of, but after two or three rewrites, the Java thing was still at least 100x slower than the tcl thing (granted, this was in the 1.1/1.2 days, but still...)
Isn't TCL almost as fast as C for certain things, like strings, but slow in other ways, like recursion? I haven't tried to do any performance optimizations yet really.
Not when you are trying to build a server on top of it.
Time to consider that your experience may be outdated. Wub, to take one example, is a pure-Tcl web server whose performance is comparable to Apache. Network latency in handling socket I/O swamps any differences in code execution speed.
I doubt very much it could compete with our Apache/IIS plugin module, which had quite a few architecture layers moved from Tcl into C throughout its life.
And in the end we gave up for .NET.
It can be fairly fast for many use cases (specially because of async processing) and it was the basis one of the original scalable web servers that implemented multi-threading https://en.wikipedia.org/wiki/AOLserver
AOLServer was the one we were measuring ourselves against, see other responses.
You had a web server faster than AOLServer, and you went out of business.
Hm.
We did not went out of business, I have not written that anywhere.
In fact, the .NET re-rewrite was quite successful and many of the people involved on that team went on to create a very successful product based on the field lessons we had with the Tcl version.
Really, it flies compared to Ruby...
Not really. I did some prime number crunching and it's the slowest of them all. Maybe for simple scripts working with strings, but otherwise I'd pick Lua any day. LuaJIT just runs circles around other dynamic languages, only compiled stuff is able to beat it.
Tcl - or Ruby, Python without NumPy (which is an extension) or most scripting languages are not the right tool for the job for number crunching.
Re:Extending Tcl
by ptrott2017 on Sunday May 13, 2018 @04:13PM
(#17060801)
As DavidW points out Out of the box Tcl (like most scripting languages) was never designed for numeric processing. If you want to do numerics and number crunching in Tcl use one of the extensions such as Vectcl or the Mathemtcl. Tcl's C APi makes writing extensions (or wrapping existing libs) pretty straight forward too.
Right - both Python and Tcl/Tk are intended to offload heavy processing to C functions that they stitch together with high level controls.
Note that the toplevel link is to a page full of simple techniques for enhancing base Tcl with C, Fortran, Lua etc. code, suggesting that Tcl offers the shortest path from dynamic language to serious number crunching power when it is needed.
Is that right ? I have never used Ruby. I should have my expectations on running time in check in case I do try Ruby out -- I have been meaning to.
I don’t dislike Ruby - you can do some very clever things in very little code with it. But it is far from high-performance!
Early Tcl was slow - but it was being compared to pure C. Recent Tcl is as snappy as any HLL.
Early (pre-8.0) Tcl was also literally string-processing the scripts. 8.0 brought a byte-compiler and the TclObj internal structure that maintained “native” values for types (I.e: a value “1.2” used as a floating-point value had its value cached as a float/double, versus reconstituting it from the string “1.2” every time it was needed. Note too this conversion happened nearly 20 years ago[0]. These days there’s some excitement surrounding the byte-compiling targeting LLVM[1], so faster still...
It is probably one of the best languages to extend. Sadly it is also one of the slowest.