httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apache-2.0/src/modules/standard mod_include.c
Date Sat, 14 Oct 2000 05:33:35 GMT
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Friday, October 13, 2000 2:25 PM
> 
> rbb@covalent.net writes:
> 
> > I had planned on letting this code work for a few days 
> before making these
> > changes, because I wanted to exercise the code before I 
> macro-ized it, but
> > I'm flexible.
> 
> No, I'm in no hurry to go any further down this path.  I don't think
> what is there already is worthwhile.
> 
> We don't have better performance and we don't need the change in order
> to allow modules to implement their own bucket types.

Ok... I'm confused... time to play C++ programmer here...

We've indirected the bucket object's vtble into it's own object. What's
the issue here?  Based on the cpu's cache and the frequency we hit these 
vtbls (see Roy's latest lecture), they should already land in cache.
I guess I want to know what performace hit you are seeing, it can't
simply be the indirection.

I know I go overboard in trying to make things generic myself, but if
we follow this design in the direction we are heading, the filter
knows nothing of it's upstream and downstream neighbors, only what the
-current- request and requested results should be.  So you know the
data -was- in utf-8, you know the client -wants- cp-850, and you happen
to be able to do that since you are a charset filter.

I like the thought of being able to extend -what- filters can do, and
-how- they can do them.  Extending into the vast unknown future bucket
types seems useful in ways we can't predict yet.  I'm just making certain
that your performance issue is really the issue, or did we jam things up
somewhere else?

Mime
View raw message