Re: New Memory Manager

Hi Christian, It's a clear solution, but indirect call may cause a lot of branch miss-predictions, so it needs to be tested if it can improve performance. binary compatibility is going to be broken anyway, so it's not a problem. Thanks. Dmitry. On Tue, Jan 14, 2014 at 11:38 PM, Christian Seiler <chris_se@gmx.net> wrote: > Hi there, > > > (For example: may be someone would >> suggest how to avoid check for USE_ZEND_ALLOC=0 to allow system malloc() >> usage on each emalloc() call? >> > > Rename emalloc() -> real_emalloc(), then: > > .h: > extern void (*emalloc)(size_t n); > > .c: > void (*emalloc)(size_t n) = real_emalloc; > > startup code: > > if (USE_ZEND_ALLOC is 0) { > emalloc = malloc; > } > > Probably some adjustments needed (esp. for potentially different calling > conventions, so maybe malloc() will need a small wrapper), this is just > from the top of my head. > > Note: this breaks ABI compatibility on most archs (because it changes > the symbol type). But could be done independently of anything else. > > Note 2: Depending on system architecture, each call to the function may > incur an additional (small) penalty. No idea how this compares to the > penalty of the if() at the start of emalloc(). > > Regards, > Christian > >