[Zope-dev] ZPT Optimization Opportunity

[Fred Drake]

On Mon, 27 Sep 2004 11:25:16 -0400, Tres Seaver <tseaver at zope.com> wrote:
> Yes, you read it correctly (although I think the real answer is
> "identical performance, within margin of error").

With other benefits, that's good enough, too.

> > Is there anything to indicate that memory usage is actually improved?
> 
> I'm not there yet.  This is essentially a "zero-copy" optimization;  if
> I can show that the functionality is equivalent, with approximately the
> same performance under unloaded sites, *then* I can look into whether it
> helps.

Ok; understood.

> I envision two possible benefits, which will materialize only "at scale":
> 
>    - Removing the need for the appserver thread to malloc and copy the
>      Big String *may* be a win on a memory-constrained system (large
>      allocations can induce funny non-linearities on the underlying
>      malloc implementation).  Not having to copy values, even in C,
>      should be a "pure" win, in any case.

Agreed.  Doing less is always a win, eventually.  Often in combination
with doing just a little less in lots of places, but that's ok.

>    - Returning the iterator to medusa means that the application
>      thread becomes available to service other threads that much more
>      quickly.  Even if the malloc issues can't be demonstrated, the
>      increase in concurrency *should* be a win here.
 
This is interesting.  If you're pushing content out the socket
earlier, you need to guard against failure much earlier, or be willing
to deal with it in different ways.  This is likely less of an issue
for sites that have been well-tested and are considered ready for
production.

I'll need to review the patch more carefully, especially since I don't
know much about the Medusa layer.  Does the modified code deal
properly with errors encountered late in the transformation of a
template?


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation