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
