Re: Performance issues with our internal memory allocator

Hey,

On Mon, Sep 28, 2015 at 3:29 PM, Noel Grandin <noelgrandin@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