On Mon, Sep 03, 2001 at 09:08:24PM -0700, Aaron Bannert wrote:
[...]
> - I've spent the entire weekend testing this code, and although I can't
> yet say it's as fast (2-5% slower) as the old code (some places are
> still lagging, haven't figured out why), I would not be posting it
> here unless I was confident enough in it's functional correctness
> for public review.
[...]
> - From my rather extensive testing, this is in my opinion as functional
> as the old apr_lock_t api. I have tested the new functions in modified
> httpd-2.0 and found them to operate correctly (although surprisingly
> slightly slower in the various MPMs :( I'm still working though -- and
> with this patch we get more eyes staring at the code).
>
> - As a side effect I've found a way to speed up a thread_mutex a wee bit.
[...]
Just a point of clarification: I have every expectation that the new lock
API will indeed be faster. In my own performance tests using the new
lock code, it is operating faster. When I say "slower" above, I should
have said that in my changes to httpd-2.0 to implement the new locks,
I was seeing a reduced requests/second rating. I expect this to go away
when all the kinks are worked out of the API.
It implementation should be identical to the old API, with a small number
of the function pointers removed, with some other small performance fixes.
-aaron
|