Thanks for you reply. On Sat, 31 Aug 2013 12:20:04 +0200 Michael Stahl <mst...@redhat.com> wrote:
> although as far as i vaguely remember the really "bad" system memory > allocators are in Windows XP and earlier; the Vista and newer allocators > are said to be much better. It is a interesting things. I tried to watch memory usage on XP and 7, And the output is a little different. > and i would suspect if LibreOffice requires more memory than MS Office > it is most likely not because of the memory allocator but because of > sub-optimal data structures in the application cores (plus some constant > overhead because LibreOffice is portable and thus needs more platform > abstraction layers). >From my inspection, VCL calls quite many malloc/free pair (in the face, new() call of some objects). UI compornent on LibreOffice supported many platform, so it woud be unavoidable. > i don't know why this does not work for the specific case of > soffice.bin, because i don't know what symbols are in the extra > libraries you link. perhaps there are different calling conventions in > the jemalloc library and the soffice.bin objects or something like that, > so it still picks up the allocator symbols from msvcrt.lib. Thank you your comment. I tested building avery small program with jemalloc, and it seems fine. So I check build related things again. > this does not work on Windows because DLLs do not have a global symbol > namespace, their namespace is local to each DLL. and every DLL knows > not only the name of an imported symbol, but also which other DLL it is > imported from. so i think what you would need to do to replace the > memory allocator on Windows is to link _every_ DLL and executable > against your custom allocator. Actually, I also tried to modify another link commands, almost passed the build but cli_maker was not. > oh, and for quite a lot of classes in the code base a custom memory > allocator is used anyway due to overloading operator new for the > particular class, see include/tools/mempool.hxx and the underlying > rtl_cache API in include/rtl/alloc.h. this implements a SLAB like > allocator which is used for the most-used classes and should be quite > efficient and reduce the fragmentation considerably. Sounds good. So I understand that LibreOffice supports jemalloc in many Unix-like systems but Windows is not. And many classes are used internal memory allocator on Unicos and Windows. Is this right? _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice