Build with jemalloc
knok at daionet.gr.jp
Sun Sep 1 18:01:11 PDT 2013
Thanks for you reply.
On Sat, 31 Aug 2013 12:20:04 +0200
Michael Stahl <mstahl at 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.
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?
More information about the LibreOffice