You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Ames <gr...@remulak.net> on 2007/01/05 19:58:10 UTC
[PATCH] speed up apr_pollset_remove
the current apr_pollset_remove has an O(n**2) scaling issue which is likely to degrade the
perfomance of the httpd Event MPM when it is handling lots of connections. I've been
playing with the following patch off and on but never posted it before due to day job
pressures. it serves pages for me but hasn't been stress tested.
the basic idea is to exploit the fact that the internal pfd_elem_t and apr_pollfd_t occupy
the same chunk of memory. by twiddling the internal structure, the pointer to one is the
pointer to both and no search is needed. this only changes the epoll implementation;
kqueue looks like it could work the same.
comments?
Greg
Re: [PATCH] speed up apr_pollset_remove
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Greg Ames wrote:
> the current apr_pollset_remove has an O(n**2) scaling issue which is
> likely to degrade the perfomance of the httpd Event MPM when it is
> handling lots of connections. I've been playing with the following
> patch off and on but never posted it before due to day job pressures.
> it serves pages for me but hasn't been stress tested.
>
> the basic idea is to exploit the fact that the internal pfd_elem_t and
> apr_pollfd_t occupy the same chunk of memory. by twiddling the internal
> structure, the pointer to one is the pointer to both and no search is
> needed. this only changes the epoll implementation; kqueue looks like
> it could work the same.
>
> comments?
Nice...
> --- ../apr/include/arch/unix/apr_arch_poll_private.h (revision 492706)
> +++ ../apr/include/arch/unix/apr_arch_poll_private.h (working copy)
> @@ -91,8 +91,8 @@
> typedef struct pfd_elem_t pfd_elem_t;
>
> struct pfd_elem_t {
> + apr_pollfd_t pfd;
> APR_RING_ENTRY(pfd_elem_t) link;
> - apr_pollfd_t pfd;
Since /include/arch/unix/apr_* are private, you should be able to slipstream
this in at whatever point you want.
Re: [PATCH] speed up apr_pollset_remove
Posted by Bill Stoddard <bi...@wstoddard.com>.
Greg Ames wrote:
> the basic idea is to exploit the fact that the internal pfd_elem_t and
> apr_pollfd_t occupy the same chunk of memory. by twiddling the
> internal structure, the pointer to one is the pointer to both and no
> search is needed.
I'd suggest adding this comment to the source code; might save someone a
bit of time in the future...
Bill
Re: [PATCH] speed up apr_pollset_remove
Posted by Paul Querna <ch...@force-elite.com>.
Greg Ames wrote:
> the current apr_pollset_remove has an O(n**2) scaling issue which is
> likely to degrade the perfomance of the httpd Event MPM when it is
> handling lots of connections. I've been playing with the following
> patch off and on but never posted it before due to day job pressures.
> it serves pages for me but hasn't been stress tested.
>
> the basic idea is to exploit the fact that the internal pfd_elem_t and
> apr_pollfd_t occupy the same chunk of memory. by twiddling the internal
> structure, the pointer to one is the pointer to both and no search is
> needed. this only changes the epoll implementation; kqueue looks like
> it could work the same.
>
> comments?
Cute, nice hack, I like it.
-Paul