apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] speed up network timeout processing
Date Wed, 03 Jul 2002 19:15:47 GMT
"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.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message