[Libreoffice] profiling & optimising ...

Hi Sebastian,

On Fri, 2010-11-26 at 13:42 +0100, Sebastian Spaeth wrote:
> As rtl_alloc_cache is called 600k times on writer startup I looked at
> it. 

        Ok :-) so you just fell into the first hole of micro-optimisation.
Unfortunately, vast numbers of people have dug in this hole at great
length before you, so by now the code is all hyper-optimised. You can
bet: if a function is called 100k times - someone has spent time to try
to improve that function.

        The -real- problem is, that they usually didn't bother to try to work
out -why- it is called 100k times, and fix the algorithm / code / data
structures above that caused that issue.

        This is why I was encouraged by your analysis of the configmgr stuff.
Before doing more work there, of course, it makes a lot of sense to work
out:

        A. what %age of startup time is the configmgr responsible for
        B. how much do we win by not having those extra nodes.

        A good proxy for both of these is to use the RTL_LOGFILE, thus:

        export RTL_LOGFILE=/tmp/startup.nopid
        export OOO_EXIT_POST_STARTUP=1
        export OOO_DISABLE_RECOVERY=1
        rm -f $RTL_LOGFILE ; ./soffice -writer ; cat $RTL_LOGFILE

        that should give you millisecond timestamps; run it a few times to get
an idea of the jitter on your machine.

        Now - manually edit the XML file to remove those sections that are
useless at startup - re-run the above several times and generate new
numbers: diff them - did it make a difference ? :-)

        If so - then we have a promising candidate for future work; if we can
save 10% this way, I would be thrilled - it looks fix-able without
excessive work.

> +    if (n > SAL_MAX_SIZE - 2 * RTL_MEMALIGN

        As you noticed, the compiler will just turn this into an integer
constant, so ...

> I reran with callgrind and it *seemed* to use a bit less CPU
> instructions but I am not experienced enough to really judge this.

        The thing to look for is the "Total Instruction Fetch Count" in the
bottom left of the status bar in kcachegrind. If this doesn't change by
a significant (ie. 0.5% at least) there was really no benefit to the
change.

        Anyhow - I'd love some numbers on those great XML bits you found
[ average of the lowest three of four runs' timing eg. ]. Ditto for
removing the impress.x?? and other unrelated files.

        HTH,

                Michael.
        
-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot