Hey, On Mon, Sep 28, 2015 at 3:29 PM, Noel Grandin <noelgran...@gmail.com> wrote:
> > > On 2015-09-28 03:11 PM, Markus Mohrhard wrote: > >> >> >> I'm not sure if I understand your comment. Can you please clarify what >> you mean with that? Maybe my understanding of our >> memory allocators is bad but I see not how this comment applies to the >> discussion. >> >> > I'm saying that in general I regard changing allocators as doing > optimisation in the wrong place - if your allocator is a real bottle-neck, > you would probably be better off looking at optimising the code that > __calls__ the allocator, rather than messing with the allocator itself. > > For example, if you had code that did: > vector<int> buffer; > for (int i=0; i<1000000000; i++) > buffer.push_back(i); > you'd be better off inserting a > buffer.reserve(1000000000) > just before the loop, to avoid the std::vector's resize-and-copy operation. > > But that's just my opinion, feel free to experiment away if allocators are > your thing :-) > I think there is a misunderstanding. We are using a custom allocator currently (well disabled by default since this morning) for all memory allocations. So I don't see how working on the algorithms helps here. The custom allocator there is used to work around some problems with the system allocator (apparently mostly on windows). I was only experimenting to see if our custom memory allocator is responsible for some of the performance problems that we see on the perf.libreoffice.org site. However after disabling the custom memory allocator we have up to 20% performance regressions in some test cases so I will switch back to the custom allocator at some point. I still can't explain the 200x performance regression that we see with the in-tree tests since adding one additional performance test. Regards, Markus
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
