Hi Caolán,
the patch looks good to me.
I am also surprised by the speedup (given that it always inserts at the
end of the vector array in your case). Hard to check without the actual
document. Might be problem in std::vector not detecting that the rest of
reserved space doesn't need to be moved or something?
You might try to load the document into valgrinded libreoffice just to
be sure that it doesn't mess memory.
Cheers
Radek
On Tue, 2011-07-12 at 09:27 +0100, Caolán McNamara wrote:
cmc->thb: I had some .doc documents which were awesomely slow to load
up, apparently because some polygons had to be split up into large
polypolygons due to a custom dashed line in use to draw them or
something of that nature.
Could you double check my change to basegfx2
http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=2f580a32ad5dbb46cd3897316a12aea032b9e10e
I'm *sure* its good, but the scale of speed-up from 4 minutes 27 seconds
to 11 seconds is massively more than I expected. Especially as the
insert point is at the end, rather than at the beginning or middle which
would have required a lot of memmove type operations.
C.
(gcc/libstdcx++ 4.6.0, CXXFLAGS=-Wp,-D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4,selinux enabled)
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.