Hi Jamie, I'm opposed to runtime custom allocators, but am fine with something like what you suggest. However, that has two down sides:
1. It touches a lot of callsites, 2. I have to add macros to make sure stock malloc etc are not used by mistake. If doing 2., I might as well just define them to their custom behavior. Ie, would this patch work for you: diff --git a/src/hb-private.hh b/src/hb-private.hh index 07550cb..167c067 100644 --- a/src/hb-private.hh +++ b/src/hb-private.hh @@ -54,6 +54,19 @@ #include <stdarg.h> +/* Compile-time custom allocator support. */ + +#if defined(hb_malloc_impl) \ + && defined(hb_calloc_impl) \ + && defined(hb_realloc_impl) \ + && defined(hb_free_impl) +#define malloc hb_malloc_impl +#define calloc hb_calloc_impl +#define realloc hb_realloc_impl +#define free hb_free_impl +#endif + + /* Compiler attributes */ On 15-09-30 03:49 PM, Jamie Dale wrote: > Since there was no movement here I went ahead and hacked in our allocator by > redefining malloc, calloc, realloc, and free to point to extern'd functions > that I define in our application. This yielded some performance benefits for > us, so I'm hoping that a more standard HarfBuzz solution might appear at some > point :) > > If you're not keen on the idea of allowing the allocator to be swapped out at > runtime, would you at least allow it to be extern'd at compile time? I'm not > familiar with HarfBuzz coding standards, but I'd propose adding something like > a HAVE_EXTERNAL_ALLOCATOR define to control this, and then define your own > allocator functions that you'd use in place of malloc, etc. > > Basically, something like this (I currently have this code in hb-private.hh): > > /* Define our allocation functions. These may be provided by an > * external source when HAVE_EXTERNAL_ALLOCATOR is defined. */ > #ifdef HAVE_EXTERNAL_ALLOCATOR > extern void* _hb_malloc(size_t); > extern void* _hb_calloc(size_t, size_t); > extern void* _hb_realloc(void*, size_t); > extern void _hb_free(void*); > #define hb_malloc _hb_malloc > #define hb_calloc _hb_calloc > #define hb_realloc _hb_realloc > #define hb_free _hb_free > #else > #define hb_malloc malloc > #define hb_calloc calloc > #define hb_realloc realloc > #define hb_free free > #endif > > You'd then replace calls to malloc, calloc, realloc, and free from within > HarfBuzz to use hb_malloc, hb_calloc, hb_realloc, and hb_free. > > This is basically the code I already have, except I > redefined malloc, calloc, realloc, and free rather than create the > hb_*variants, as I didn't want to change too much HarfBuzz code. > > Thoughts? > > On 31 August 2015 at 22:17, Jamie Dale <[email protected] > <mailto:[email protected]>> wrote: > > Hey, > > I'm not sure if this is correct place to post/discuss feature requests... > hopefully it is. > > Our project makes use of a custom memory allocator, and we like to ensure > that our third-party libraries are using this where possible, as our > allocator can offer significantly better performance, and can also allow > us better memory profiling and debugging support. > > A look through the HarfBuzz source code would suggest that it doesn't > currently support custom memory allocators, and instead just directly > calls the standard malloc/free/etc functions. I was wondering if you'd > ever considered (or would consider) adding a way to override this > behaviour? > > In my case, I'd just need a single global override to be set before my > first call to any other HarfBuzz code... basically something like > the FT_Memory struct from FreeType: > > http://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html#FT_Memory > > Thanks, > Jamie. > > > > > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
