httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 21:44:39 GMT
rbb@covalent.net wrote:

> > > ap_r*.  These are older functions.  They are likely to always work,
> > > because they are very useful.  Currently, they have horrendous
> > > performance.  The way to solve this, is to allow ap_r* to buffer data.  If
> > > multiple calls to ap_r* are made, the buckets should be buffered until it
> > > is worth it to send the data.
> >
> > That solves the "excessive number of trips down the filter chain" problem, but
> > doesn't solve the "excessive number of buckets to
> > create/initialize/examine/destroy"  problem.  Both will cause performance hits
> > with the mod_autoindex scenario.
>
> The way to solve this is to stop allocating buckets everytime they are
> needed.  We need to keep a free list of buckets, so that we are just doing
> pointer manipulation, but nobody has had the time to implement this yet.
>

Yes, the cost of allocating/destroying buckets could be greatly reduced.  But it still
costs something, and you can't avoid setting some fields in each bucket.  Those
operations are likely to cause cache misses when the buckets are first stored into,
then again each time a filter references them many nanoseconds later.

> > > core_filter:  This filter should take the brigade it is sent, and coalesce
> > > it.
> >
> > That's too late.  This forces many more buckets to be touched on the way down the
> > filter chain than we would need to if we coalesced at the top.
>
> Touching multiple buckets is just a bit more pointer manipulation.  It is
> not a performance issue, once we have a free list.
>

Do you realize how much cache misses degrade performance on modern CPUs?

Greg



Mime
View raw message