On 18/05/12 15:38, Arnaud Versini wrote: > Hi, > > I checked on Linux and Windows, the memory after a massive allocation > and a massive deallocation is really freed, so currently la raison > d'être of our internal allocator is gone (need to be checked on Mac Os > X). About performance I don't know.
checking "a massive allocation" doesn't really tell us all that much, because allocators typically operate in 2 modes: - for large objects, directly request zero-backed memory via mmap - for small objects, maintain elaborate data structures to allocate these from arenas or whatever in the case where a single object is backed by its own mmap it is trivial for the allocator to unmap the memory on free, and i would expect every system allocator to do that (even 10 years ago); the far more interesting case is what happens when a large number of small objects of different sizes get allocated: is the allocator smart enough to release the memory when all, or a substantial number of them, are freed again? > Currently there is a mix of system allocator (or jemalloc) and our > internal allocator. I don't think it is optimal. > > I propose to delete all our allocation code and use small stubs for ABI > compatibility until LibreOffice 4.0, and we can use the system allocator > or jemalloc if there is performance issues, perhaps on Windows. > > I ask you if I could see if it is a good idea to go on this way or not, > and how (branch or trunk). i don't think there is any pressing need to do this right now, but of course you can experiment a bit, i'm also not happy that we maintain our own allocator, but i'd like to wait for LO4 with actually doing a change. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
