Joe Orton wrote: > On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote: > >> What's the point? >> > > The null hypothesis is: modern malloc implementations do exactly the > same optimisation work (e.g. maintaining freelists) that we duplicate in > APR pools. By avoiding that duplication, and relying on malloc > optimisation, we might get better/equivalent performance whilst reducing > the complexity of APR. > > So, we're testing that hypothesis. If it's shown to be false, then, we > revert back to the old allocator. That doesn't mean it's not worth > trying. >
Nah, we're not testing that hypothesis. We're testing the hypothesis that "most recent C libraries have a modern malloc implementation", which is clearly false. And we're ignoring not-so-recent C libraries, like Mladen't RHEL-4 example. If someone is certain that she can do better than pools, she can still write her own allocator and use that. > Also, I think it would be more useful to benchmark something like > Subversion's "make check", or an httpd load test. > Subversion's "make check" is strongly I/O-bound, so timings would probably not show a thing. We don't have any load tests, I'm afraid. -- Brane
