OK, I went to the bboard at aolserver and checked for new responses to my question. Jim's answer indeed makes things clearer, though as he points out the answer isn't clear :)
- Tcl scripts are recompiled every time a page is visited
This indicates 8.3 ain't a particularly good choice for the ACS at this time, as compile overhead will more than eat up any execution savings for simple scripts. Tcl scripts are source'd, and there's no way for AOLserver to save and reuse the compiled bytecode that results.
- A Tcl proc registered to a URL is compiled once
Not much to add to this!
- Tcl embedded in .adp pages is only compiled once
Another argument in favor of using adp pages rather Tcl scripts. Apparently the adp page parser calls the compiler directly and is able to save the results.
AOL has switched entirely to adp pages and the AOLserver folks more or less deprecate Tcl scripts, with Kriston being particularly critical of the ACS's use of them and suggesting aD rewrite their code. Fat chance :) So the supposed inability to cache bytecode for Tcl scripts may simply reflect the fact that they really would like Tcl scripts to go away.
- adp pages don't really run faster
The underlying string operations run slower as 8.3 correctly handles multi-byte characters, etc. The compiled bytecode runs a lot faster (after the first compile). There is more lock contention with 8.3 (for most of us probably not a serious problem, for AOL with its high load and high concurrency a problem). AOL's experience is that the slower underlying string primitives more or less balance out the gain from bytecode rather than pure interpretive execution IN THEIR ENVIRONMENT AND IN THEIR CODE.
Jim points out that 8.3 also hits the heap in ways that causes lock contention in the heap management code, something AOLserver avoids if you use the -z ("zippy" heap management) option.
He also points out that they find binary file I/O a boon in their download server apps.
No simple answer. For the ACS, at the moment I suspect that 7.6 wins pretty handily
