Jim Wilcoxson wrote:
...
> 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.
The ns_share stuff is very sensitive to the performance of the
memory allocator across threads. This has fluctuated over time,
and I believe the one in the current aolserver head is the best
so far. Earlier 8.x versions were not as good as the 7.6 version,
and the default one in Tcl was really bad for threads. I'm
currently working with Jim Davidson to incorporate the much faster
threaded allocator into the core for 8.4.
Another thing that might be noted is that Zoran Vasiljevic (main
guy doing the Tcl Thread extension) mentioned, I believe, that he
had a somewhat different shared variable implementation in the
Thread extension that was faster than the AOLServer one. I'm not
really sure, as it was just a newsgroup comment in passing.
Also, I believe you implied that you were using a proc, but it is
important to note that toplevel code will be slower if large loops
are used without putting them in procs. This is by design. The
feeling was that toplevel code is only ever evaled once, and thus
doesn't need to be compiled. However large loops would always
gain a compilation benefit, so they should be in procs. Some other
pointers about this at http://wiki.tcl.tk/348.html. Perhaps we
should always compile loops ...
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
