apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PATCH] speed up network timeout processing
Date Wed, 03 Jul 2002 20:08:40 GMT
> From: trawick@rdu88-250-182.nc.rr.com
> [mailto:trawick@rdu88-250-182.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 03 July 2002 21:16

> "Bill Stoddard" <bill@wstoddard.com> writes:
> 
> > > Have either of you benchmarked with apr_poll() or are you assuming that
> > > the problem exists?
> > >
> > > Ryan
> > >
> > >
> > 
> > Sorry didn't answer you here... There definitely are extra instructions and
> > function calls involved with using apr_poll() in this case. I don't know the
> > exact number but I could find out. The affects of a few dozen extra
> > instructions would be insignificant in overall server performance, but you
> > can say that about any place in the server. Adding function call overhead
> > adds up. In this case, is easy to just avoid the extra calls altogether with
> > no significant loss in code readability.
> 
> Using apr_poll() is more complex than using poll() in this situation.
> We'll have to be careful not to leak storage (i.e., create/destroy a
> subpool or attach the apr_pollfd_t to the apr_socket_t the first time
> we need to wait_for_io_or_timeout.  And since this deals with more
> than just sockets we'll have to play with the interface to
> wait_for_io_or_timeout.  So we munge a lot of code so that we only
> call poll() from one place and we're left with extra complexity and
> extra pathlength.
> 
> An implementation using apr_poll() which is more complex and less
> speedy by inspection than using poll() directly is going to be
> vetoed.

Oh, come on guys, let's not play the veto card so early.
By inspection != real performance.  Numbers first.

Sander 'sounding a bit more harsh than he means to'


Mime
View raw message