On Thu, 2011-09-22 at 17:09 +0100, Caolán McNamara wrote:
On Wed, 2011-09-21 at 11:28 +0100, Michael Meeks wrote:
It'd be really interesting to get a callgrind trace of ods / xlsx loading.
oh, as an aside, this is easy to get with
cd sc
export VALGRIND=callgrind
make -sr
Here's mine FWIW http://www.skynet.ie/~caolan/pub/tmp/callgrind.out.4171
Seems to spend all its time getting and setting optimal row
heights/widths or something like that in ods/xlsx mode.
Yes. That's an infamous bottleneck. Calc's row height adjustment on
file load is pretty darn expensive. It basically re-calculates the
heights of rows in all rows regardless.
The xls import used to suffer the same thing, but we've replaced that
with using the row heights stored in the xls directly, which
coincidentally improved the layout preservation with Excel documents as
well (and loads much quicker).
In theory, we could skip that for xlsx too, by doing the same thing we
did for xls since xlsx too store the row height with the document.
Not sure if ods stores row heights, but if it does, then we can do the
same thing for ods too. That's worth a check.
As an aside, dbf and csv import had the same issue, but I've reduced the
need to re-calc row height to only those rows that really need
re-calculation. Needless to say that resulted in a much faster import
especially for large dbf and csv documents. Much faster.
Kohei
Context
- Re: [Libreoffice] Proposal: slowcheck -- a new gbuild toplevel target (continued)
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.