On Fri, 2012-03-02 at 20:46 +0100, Radek Doulik wrote:
> On Fri, 2012-03-02 at 19:51 +0100, Radek Doulik wrote:
> > thanks. The patch looks good to me. Pushed.

        I just pushed a lot more of this stuff to master, basically out-lining
all those (exception throwing => hard-to-optimise) object constructors
into helper functions:

        This starts to tackle the size issue:

Before:
-rwxr-xr-x 1 michael users 20132128 Mar  2 20:18 /tmp/libooxlo.so
After:
-rwxr-xr-x 1 michael users 17906624 Mar  2 21:58 /tmp/libooxlo.so

        ie. an overall 10% / ~2Mb of (stripped) size saving at -O0 - which is
about 50% of the size of the customshapepreset* code (judging by the
stripped .o file sizes).

        This makes me wonder what other rabid wasteage there is in oox -
particularly around XSLT code generation (is that going on in here?),
20Mb is really not a small thing, at-all.

        I managed to get my compile time down too:

Before #2:
        0m16.993s
After:
        0m4.776s

        Which looks like it's finally 'fast enough'.

        Of course, I havn't done any run-time profiling of document load, I
don't think anything I've done should have any noticable negative impact
there, indeed hopefully quite some positive impact - profiling would be
the way to go there clearly.

        Anyhow - I'll butt out at this point, IMHO this is 'fixed'.

        It'd be nice if you could do your more advanced correctness checks; eg.
I assumed that a EnhancedCustomShapeParameterPair only ever has two
sal_Int32 Value members - pragmatically that appears to be so, but ...
anyhow we assert fail if not during the generation (I hope).

        I'm not sure if we want all that in -3-5 but if you're happy we could
do that.

        ATB,

                Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to