apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Lamb <sl...@slamb.org>
Subject Re: Compile-time vs. run-time checks
Date Tue, 24 Feb 2004 04:09:48 GMT
On Feb 23, 2004, at 1:43 PM, Greg Stein wrote:

> On Mon, Feb 23, 2004 at 01:33:31PM -0600, Scott Lamb wrote:
>> I'm putting together a patch to use SO_(RCV|SND)TIMEO for
>> apr_socket_timeout where available; I expect I'll find it has better
>> performance on some platforms, as it would no longer require using
>> non-blocking IO and preceding every read() and write() with a 
>> select().
>> (I intend to try benchmarking Apache on Darwin, where the system call
>> overhead seems to be quite high.)

It seems I was way off...I've got my somewhat tested but unpolished 
patch attached, but unless someone else runs benchmarks and sees a 
speedup, I see no real reason to apply. I couldn't see a statistically 
significant difference between them. In transferring either big or 
small files with httpd-2.0 HEAD and ab over loopback on Darwin 
(keepalive on). Which I'd think would be the ideal situation for seeing 
an improvement...

I'm surprised. System calls seem to be an order of magnitude slower on 
Darwin than they were on Linux for roughly comparable hardware, so I'd 
expected to see the extra overhead being significant in some way. But I 
guess it was just such a small piece of the whole that it didn't matter 
anyway. Or something.

>> On some older versions of platforms (Linux 2.2), these #defines exist
>> but do not work - it's not possible to set them. Can I assume that if
>> APR is built with a kernel in which it does work (Linux 2.4), it will
>> be run with one as well? Or should I include a runtime check for this
>> option?
> Icky. I don't think it is really possible to make that assumption.
> Thankfully, I also believe this is reasonably solved with a global
> variable (i.e. race conditions around coming up with the same flag 
> don't
> apply :-), and the value certainly won't change over the process'
> lifetime).
> I would recommend a dynamic solution for now. We may be able to make 
> that
> compile-time for certain platforms, where we know "all" versions handle
> the flag properly [when present].

Thanks for the suggestion. Maybe I'll apply it to the next patch. :/

> Cheers,
> -g


View raw message