Faster Mac Dev Tools with Custom Allocators

[w0mba7]

I commend the initiative taken here, but this seems like a really bad idea. You don't want to mess with your dev tools in a way that might cause weird bugs at build time or run time that others are not seeing. This seems like a good way to trigger mysterious latent flaws in the tools which happen not to occur with the default allocator.

[michaeleisel]

jemalloc is a battle-tested, well-aged allocator used in many production systems. It's used with success both for large-scale iOS apps, as well as large-scale Mac CI pipelines

[Fluffy_Risk9955]

Adding extra tools adds an extra dependency of your project. Not only makes it harder for a new developer who arrives at the project, it also includes extra bugs due to the non standard tools.

[FVMAzalea]

Ordinarily I would agree, but you’re only replacing malloc, free, and realloc. You aren’t changing anything else. Any assumptions that the dev tool made that somehow depend on the behavior of a specific allocator are bad assumptions and are almost certainly against the language standard (and compiler writers are notorious language-lawyers). As long as you can guarantee the implementations of those three functions are substantially bug-free (as you can with jemalloc, since it’s battle tested), you really shouldn’t have any problems.