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

[Vlad S. <vl...@cr...>]

You are right and now i see that Naviserver does not do this right 
because our global cache keeps strings only. It looks like waste of 
resource now caching file contents only but ns_share uses Tcl_Objs 
internally, so it is possible to use it instead maybe?

Andrew Piskorski wrote:
> 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?
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/