Jason van Zyl <[EMAIL PROTECTED]> writes: > I think the idea is good but it definitely has the very strong disadvantage > of not streaming. All the output is buffered before being sent to the > browser which is bottleneck. I have seen this and Daniel has also notice > performance problems with this model. I myself am going to try and come up > with something that will be convenient like the classic model but stream > instead of buffer.
Yup, exactly. Hopefully we can figure out a way to use something almost exactly like the existing screen/nav/layout setup, while streaming the output of each merge instead of buffering huge strings. The buffering really slows things down, especially since the buffers used by Turbine are created new for each use. This really gives the heap a work out (and because of that, your CPU as well). In Apache's httpd, the Apache Portable Runtime (APR) deals with memory management issues like this by using passing around pre-alloc'd pools which server code can dip into whenever memory is needed. Even though we could improve the performance of the existing code by using pooled buffers, a streamy approach will yield much better results. I'm hoping we can do something like a queue of streams to replace the old String creation non-sense. :) Daniel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
