> > On Saturday 09 November 2002 19:43, you wrote: > > > Since the TCL core already has all this stuff in it about binding TCL > > vars to C vars, it seems plausible to use it for ns_shares and get > > 7.6-like performance without needing traces. > > Ehm... the Tcl bindings *use* traces internally, i.e. on the C-level.
Okay. I am showing my ignorance then. :) > Speed? Yes, I admit. it would be slower. But how much? Given the > skyrocketing CPU speeds, I'm more concerned about the implementation > maintainability then some-% speed penalty. The test I ran to compare 8x with 7.6x was a 10-line loop, around 400K iterations, setting 2 ns_share arrays. Because of TCL 8x compilation, I expected it to go faster, but instead, it was around 3x slower. That doesn't mean our site will be 3x slower of course, but it didn't encourage me to jump on the 8x bandwagon - that's all. > > We have lots of TCL code and lots of ns_shares on our site. So aside > > from my philosophical dislike of nsv's, there's just too much code for > > us to change, both time-wise and risk-wise. > > Is the "philosophical dislike" based on the Tcl-side of the matter > (i.e. need for wrapper commands) or the underlying implementation? I am spoiled by having true shared variables that act like TCL variables in all aspects, ie, can be passed w/o the caller knowing whether they are shared for example, writing a ton of code with that paradigm, and then having it taken away and given "a way to share data among threads", which is not a TCL variable. To me, nsv's are a very different animal. For people just starting out, it's probably not a big deal. They can write their code to whatever shared data interface is available. We have 933 ns_share statements across 407 TCL source files, so the impact of changing all that code is very high for us. I do appreciate that you have the ability to consider and/or implement alternate shared var mechanisms. I can only talk about it. :) Jim
