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
