+1 on switching the default to mimalloc meanwhile keeping jemalloc as an alternative.
*Regards,* *Rossi SUN* On Tue, Jun 11, 2024 at 2:38 AM Anja <anja.kef...@gmail.com> wrote: > I do know of use-cases where users explicitly set jemalloc as their > preferred allocator. I would recommend keeping it. > > On Mon, 10 Jun 2024 at 08:09, Antoine Pitrou <anto...@python.org> wrote: > > > > > Hi Kou, > > > > Le 09/06/2024 à 09:16, Sutou Kouhei a écrit : > > > > > > Questions: > > > > > > 1. Do we need to keep jemalloc support? Compatibility? Can we > > > drop support for jemalloc to decrease maintenance cost? > > > > I'm not sure there's much maintenance cost. I expect some people might > > prefer jemalloc, and perhaps it performs better on some use cases. So > > for now I would recommend keeping it. > > > > > 2. Is it OK that we add support for system mimalloc? > > > > Hmm... that sounds legitimate, but with the caveat that a system > > mimalloc can override the standard malloc/free functions. Would that > > affect an application using Arrow C++? > > > > > FYI: In general, I want to use system libraries as much as > > > possible. But we can't use system jemalloc for bindings > > > because most system jemalloc don't support dlopen(): > > > https://github.com/apache/arrow/issues/32530 > > > > We use something similar for mimalloc: > > > > > https://github.com/apache/arrow/blob/036fca0ae5c8956c83b69478d413c24f32398f8c/cpp/cmake_modules/ThirdpartyToolchain.cmake#L2223 > > > > Regards > > > > Antoine. > > >
