On Thu, Jul 13, 2006 at 04:53:51PM -0400, Andrew Piskorski wrote: > On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote: > > > Except... Rob found a neat way to cheat by passing the script as an > > arg to a do-nothing 'for' command. 'for' compiles the script for you. > > Very smart and hellish to read...
> But if that's the case, then what does any of this have to do with > per-thread caches? As you said, Naviserver is already cacheing the > string source of *.tcl pages, so what's preventing you from using the > same for/eval trick Rob used, for each interp? > (I must be missing something here...) Oh, the snippet of file.tcl Vlad posted talked about: bytecode, which will be associated with the Tcl_Obj we just cached (as its internal representation). Which maybe answers my question... I suspect that: The Tcl interp is able to cache and re-use the bytecode for procs, because the proc persists - its Tcl_Obj hangs around. But if you hand the Tcl interp a script snippet (e.g., the entire contents of a *.tcl page), yes a Tcl_Obj is created, but as soon as you're done evaluating the script, that Tcl_Obj's reference count drops to zero and it goes away. Thus there is no persistent Tcl_Obj around to hang the byte code internal-rep on unless you explicitly create one. And, Rob used a per-thread (or per-interp?) ns_cache to create that persistent Tcl_Obj. Something like that? Could a Tcl namespace variable of some sort also be used to provide the persistant Tcl_Obj for the *.tcl script? -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
