apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: [PATCH] speed up network timeout processing
Date Wed, 03 Jul 2002 16:05:14 GMT
Ryan Bloom wrote:

>>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.
>

My concern is that you're obscuring a fundamental point: different
applications have different performance needs.  Sometimes a lightweight
library function performs adequately for the target application.
Sometimes you have to inline to implementation because you're using
it in code where speed is more critical.  In order to make apr_poll()
suitable for *all* applications, from a performance perspective, we'd
have to turn the entire function into a macro so it can be inlined.
But that's a bad idea for a lot of other reasons, so we leave it a
function so that it meets the needs of 99% of the code that might
want to use it.  The other 1%, the 1% with the most extreme performance
concerns, will always need a custom solution.  That's no different from
our use of libc: we try to use a function in the public API if it's
helpful to do so, but we write an inline equivalent in cases where
we need the highest possible speed or specialized semantics.

>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.
>  
>

We've made no promise to users of APR that APR functions will be
implemented as calls to other APR functions, and IMHO it wouldn't be
helpful to users if we ever did so.  The promise that APR makes to
its users should be: "each function in this library's public API
is as well-tuned as we can make it."  That's much more useful to
a customer of the library than a promise "each function in this
library is implemented via calls to other functions in this library."

--Brian



Mime
View raw message