Thanks for the info Jeff. My understanding is that the TCL 7.6 ns_share stuff is hacked into the TCL interpreter variable handler, while the 8x ns_share routines use variable traces. I had wondered about using the C variable facility to do ns_shares but haven't messed with it. It seems possible, although there is no way to unset a C variable but an ns_share can be unset. I'm sure many more issues than this... LOL.
FYI, the loop was contained in a proc in a TCL file that is loaded during startup. So I assume it was compiled. We're using the standard allocator, not -z. Jim > > 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 >
