Luke Kenneth Casson Leighton wrote:
On Fri, Jul 27, 2001 at 12:05:02AM -0700, Brian Pane wrote:
hmmm...looking at the code, it makes sense that SMS is half as fast as the original pools code. I didn't realize this until just now, but the polymorphism in the SMS framework will probably make it impossible to match the performance of pools:
* The SMS-based implementation has to do essentially the same work, but it also does an extra function call (apr_sms_malloc calls apr_sms_trivial_malloc).
okay: how about this. in the cases where fast-optimisation is really really needed, how about calling the apr_sms_xxx_yyy() functions or even just function, direct?
In Apache, there can be hundreds of apr_palloc calls per request . To avoid performance degradation, we'd have to bypass apr_sms_malloc and call apr_sms_trivial_malloc for almost all of them. And then we'd have to change them all if we switched from sms_trivial to some other type of SMS.
I was thinking about a macro-based solution,
#define apr_palloc(sms, n) (sms)->malloc_fn((sms), (n))
but even that has problems (it requires exposing the struct definitions in apr_sms_private.h to code outside of APR).
--Brian
