On Friday 25 February 2005 19:16, Andrew Piskorski wrote:
> On Fri, Feb 25, 2005 at 12:58:45PM -0500, Dossy Shiobara wrote:
>
> > Zoran's "ttrace" extension might help here, but "ttrace" doesn't give
> > you the performance boost of Tcl's parsing and byte compiling on first
> > execution, and subsequent executions are just calls into the bytecode.
>
> I'm not sure what you mean there. I haven't looked at the code, but
> my understanding is that ttrace uses the Tcl "unknown" proc to look up
> and copy procs from a server-wide store into the local interp, when
> each proc is first called. Thus, you take a performance hit on the
> first call of each proc, but from that point onward calling that proc
> works exactly the same way as it would in stock AOLserver without
> ttrace. Is that correct?
>
This is correct. And, in my experience, I have not noticed
any speed penalties. OK, others may get different metrics
(depending on the app). What you get is: about 1/3 of the
memory footprint and much faster thread creation. To startup
one thread/interp fully loaded, we need about 2 sec on a 2.4
GHZ Linux. With ttrace it is about 50 msec. Still a lot of
time but it is all Tcl now. If rewritten in C, this could
be even less.
> ttrace looks like a win-win situation to me. If you want certain
> procs pre-loaded into the interp, it should be feasible to add some
> sort of ttrace hook to greedily install those procs into every new
> interp. And if you used that hook for ALL procs, every single one,
> then you'd basically be back to exactly how stock AOLserver behaves
> without ttrace, no?
ttrace is already doing this:
ttrace::preload register procedures to be preloaded always
Those will be loaded always and other will be loaded by the
"unknown" first time they are referenced.
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
