From: Andrew P. <at...@pi...> - 2005-12-30 05:32:46
|
On Thu, Dec 29, 2005 at 07:11:35PM -0700, Stephen Deasey wrote: > Still to think about are per-thread Tcl caches. The main reason for > these are that you can put Tcl objects in the cache, not just their > string rep, which is particularly useful for already-compiled byte > code -- i.e. for *.tcl pages. Tcl code in *.tcl pages (not in procs) can be, has been, and I hope currently still is cached in OpenACS using the mechanism Rob Mayoff added to AOLserver 3.3 long ago. Essentially, all Tcl code in each *.tcl page is automatically "compiled" to Tcl procs on first execution, and those procs' bytecode is then cached via ns_cache. Each connection thread does its own entirely independent cacheing, but it worked fine and apparently was a substantial speed up for some ACS sites when switching from AOLserver 3.3+ad11 or 3.3+ad12 (I forget which) to 3.3+ad13. Actually, I'm not sure whether that code is currently active or not. It sounds as if the feature may have broke during the AOLserver 3.x to 4.x transition and never been repaired. See here for more info: http://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152 Does Rob's cacheing cover the functionality you want, or are you thinking of cacheing of some other sort of Tcl objects? > The best solution for caching byte code might be to share the > mechanism with ADP pages. They currently have a pre-thread cache of > script blocks, and a per-server cache of text blocks, for each page. > AOLserver 4.5 adds a per-server output cache. We could use this for > *.tcl pages as well, perhaps negating the need for per-thread Tcl > caches. That still leaves Tcl objects like lists or dictionaries that > you may not want to stringify on each access. Ah. I think Rob's code above solely cached compiled Tcl bytecode (in what form I don't know), not Tcl_Obj representations of anything. I've also no idea whether it plays nicely with Zoran's Ttrace extension or not. But, we already have centralized server-wide cacheing of Tcl_Obj's via Zoran's Tcl Threads Extension, right? So, is there any real use case for a per-thread Tcl_Obj cache? (Offhand I can't think of one, but then I don't think I've ever really used ns_cache directly at all, only the simplified util_memoize facility of OpenACS, so I'm not the right person to ask.) -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |