apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [PATCH] speed up network timeout processing
Date Wed, 03 Jul 2002 15:37:51 GMT
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> 
> "Ryan Bloom" <rbb@covalent.net> writes:
> 
> > > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > >
> > > "Ryan Bloom" <rbb@covalent.net> writes:
> > >
> > > > > From: trawick@rdu88-250-182.nc.rr.com
[mailto:trawick@rdu88-250-
> > > > >
> > > > > A little bird told me that FD_ZERO() burns lots of cycles in
> > > > > apr_wait_for_io_or_timeout().  It turns out that this is an
easy
> > > > > conversion to poll(), which doesn't have such overhead in the
> > > > > interface.
> > > > >
> > > > > This works for me with some testing (timeouts on read and
write
> > work
> > > > > for me).
> > > >
> > > > Can we remove the #ifdef's by just using apr_poll here?
> > >
> > > I'd rather we not, since that introduces a fair amount of extra
> > > overhead.
> >
> > Then let's get rid of the overhead.
> 
> redesign the API

The redesign the API, but FIX the performance problem!

> >                                        If we don't use apr_poll,
then
> the
> > overhead is maintenance,
> 
> the marginal extra maintenance is certainly something I can live with
> here...  this is an important path within APR...  if we can use the
> most efficient mechanism without much extra maintenance then we
> should...

You are missing the point.  If apr_poll() is to be useful to external
projects, then it must perform well.  If it performs so poorly that we
refuse to use it inside of APR, then it couldn't possibly be useful to
external projects.  That is straight-line reasoning in my mind.

Why in the world would we leave an API in APR that performs so poorly
that we refuse to use it in our own library?  Doing that boggles my
mind.

Ryan



Mime
View raw message