On Wed, Feb 25, 2015 at 10:17 PM, Konstantin Ritt <ritt...@gmail.com> wrote: > Maybe a bit off-topic: can we introduce our own (probably customizable) > memory allocation API, something like Apple's CFAllocator [1], and move Qt > internals to use it instead of malloc/realloc/free (and maybe instead of > some new/delete-s, based on some policies)?
Before you go all-out on something like that, please make sure you benchmark and consider the cost. Memory allocation is already something that is quite slow, and yet, done a lot - all over the place (too much, even, but that's a rant for another day). IIRC when I pushed for deprecating qMalloc/qFree in the past, I measured (on Linux) a ~10% time penalty for small allocations, lowering to 0-5% as allocation size increased. That's a way too hefty penalty to ask people to pay on something so universal - and that was literally just a function wrapping malloc, no "debugging or monitoring". Furthermore, aside from performance, I don't think that reintroducing a wrapper is a smart way to do it for much the same reason why I wanted to get rid of them in the first place: they weren't universally used, leading some people to get the false impression that intercepting qMalloc would give them the kind of diagnostic information you're talking about. If you want to debug or monitor, then I'd suggest doing it a lot more centrally with something dedicated to that task, see e.g. heaptrack (http://milianw.de/tag/heaptrack). _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development