When we evaluated 3.4 performance (TCL 7.6 and 8x) vs. 2.3.3 (TCL 7.4), one thing I compared was a 10-line loop to load an ns_share array. The loop contained maybe 8-10 string operations on a string of around 200 characters, and a single "set" command with an ns_share array lvalue. One execution of the procedure takes something like 3 minutes, i.e., TCL 8x does one compile and then executes for several minutes.
I couldn't find the exact benchmark results just now, but it was something along the lines of 3.4 w/7.6 being 80-90% faster than 2.3.3/7.4, and 3.4 w/8x being only 25% faster. So in this case, the TCL 8x compiling and faster string operations were greatly outweighed by just 1 ns_share variable being set. This performance difference is the reason we didn't migrate to 8x. Just a data point that sites making heavy use of ns_share may want to consider. Jim > Ah yes, the lifespan of Tcl 7.6 has certainly been longer than many > expected, or perhaps wanted ... There are so many reasons to upgrade, > and very, very few not to. At the Tcl level, script compatability > was near 100% (it was Tk 4.x -> 8.x that was more sensitive). The > main reason is speed. Check out the data at: > > http://wiki.tcl.tk/1611.html > > That indicates a 6x overall speedup from 7.6 -> 8.0. I'm now working > on 8.4 to push that boundary even further (already beating 8.0 by 20% > and we're not done yet). > > Then of course there are the new features. More advanced regexp, new > string functions, transparent unicode support throughout, 'binary', > 'namespace', more 'file' commands, ... > > Recall that the last patch release of 7.6 was in January 1997! A lot > has happened since then. > > Jeff Hobbs The Tcl Guy > Senior Developer http://www.ActiveState.com/ > Tcl Support and Productivity Solutions >
