Re: [naviserver-devel] Cache compiled Tcl page bytecode

[Andrew P. <at...@pi...>]

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 <at...@pi...>
http://www.piskorski.com/