On Monday, January 6, 2003, at 11:10 PM, Jeffrey Hobbs wrote:
That's a good question ... I've never actually done performance
analysis on the stacked channel stuff, but it is fairly efficient.
It just passes buffers from one stack to the next as they are
consumed. Special purpose filters may do a better job as they
can suck in large amounts of data as they operate, but I'm not
sure that you'd win if you have to have extra exec overhead.
What would be a good test?
I suppose timing SSL connection throughput using Tcl stacked channels
via the Tcl C API and a straight C implementation.
If the channels have configurable buffer sizes and such they may work
well, i.e. all channels in a stack should have the same buffer sizes,
the exception being for a channel whose output is larger than its input
(a decompression channel, for example) -- the channel that gets that
output should also reasonably be expected to have a larger buffer size.
Jim D., Nathan and I were just discussing the comm model in AOLserver.
For 4.x, Jim has created a very aggressive read-ahead comm model that
isn't suitable for all types of network usage but is very suitable for
dealing with HTTP content. I'd be surprised if Tcl stacked channels
could match the speed and efficiency of this model, and in AOLserver's
case, specialized code to do this is worth the fact that it's not
generalized to handle any type of case.
My suggestion was that we allow multiple comm models in AOLserver (and
Tcl?) such that the one best suited for a particular task could be
selected by the module or code that needs it. An HTTP connection might
work great with the aggressive read-ahead model, for example, but SSL
connections might not. Having a means in AOLserver's C API (and/or in
Tcl's API) to choose which comm model, or transformation model (i.e.
what channel type) to put into a stack would allow more flexibility.
/s.
In any case, I did want to mention that since 8.2 Tcl has had stacked
channels in the core. Extensions like Trf, memchan and TLS use this
to do compression and/or encryption on channels transparent to the
user.
I create a new channel type in tclcmds.c in the nsopenssl module to
allow Tcl's gets, puts and friends to work with an SSL "socket",
though
I didn't use channels for the C API portion of the process.
Are there any performance issues with stacking channels?
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
