Performance issues with our internal memory allocator

[Michael Meeks]

Hi Markus,

On Sat, 2015-09-26 at 20:51 +0200, Markus Mohrhard wrote:
> so we have been running our in-build performance tests now for a few
> weeks and recently discovered that our internal memory allocator is
> causing spikes in the runtime.

	What fun =) the irony is that it was written to avoid exactly such
spikes (which were primarily on Windows) ;-) Thanks for finding this
one !

>  It became even worse during the weekend with the tests taking 200
> times the instructions. Most of it seems to be spend in our memory
> handling code and not really in the actual code. (see for example
> http://perf.libreoffice.org/perf_html/ftest_of_cppu_sc_on_vm139.details.html with the annotated callgrind ouput at http://pastebin.com/ELC64s1n).
> We had a profile that showed the issue inside of the memory allocator
> much better but I have to find it again.

	Interesting. We found a really silly one in the ::Interpret just
recently, and have a simple fix - that could cause some excessive
allocation - but I forget if Tor merged that to master (yet).

	TBH - I find using kcachegrind -incredibly- more useful than the
annotated output above.
> 
> Is the internal memory allocator really still useful despite showing
> sometimes really bad behavior ?

	I'd say not myself. My hope is that the windows allocator has also had
some work done on it since ~2005? when the issue was worked around by
mhu.

>  Personally I would just fall back to the system memory allocator
> except for the few cases where we know that it makes a difference
> (small memory blocks in calc formula tokens, ...)

	Right - it should be far quicker, particularly on Linux.

	I'd love to see how a change like that impact the profiles; worth a
commit to master and a quick revert later if there is a visible issue
anywhere I guess =)

	Then again - I think we're going to need a custom allocator of some
kind (though prolly rather slow & dumb) for LibreOfficeKit
pre-initialization for cloudy bits - so; perhaps that allocator may be
useful in the end temporarily for that.

	ATB,

		Michael.

-- 
 michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot