[Libreoffice] Proposal: slowcheck -- some numbers for sc
caolanm at redhat.com
Wed Sep 21 04:09:02 PDT 2011
On Wed, 2011-09-21 at 11:28 +0100, Michael Meeks wrote:
> On Wed, 2011-09-21 at 09:50 +0100, Caolán McNamara wrote:
> > So I've now added a timer listener to our cppunit launcher to tell us
> > how long each test takes and indeed it takes about 70ms to load a
> > .xls, 370ms for an equivalent .ods and about 500ms(?!) for an
> > equivalent .xlsx
> Ooh :-) pretty numbers indeed, how can I reproduce them ? I notice they
> didn't go to the console (which is a shame), and couldn't see them in
> the sc_filters_test.log file either (oddly).
edit cppunittester/cppunittester.cxx, define TIMETESTS
(should see the times for the sal cppunit tests on stdout because those
ones are not gbuild-ified)
deliver -link; cd sc; make -sr;
grep ms ../workdir/unxlngx6/CppunitTest/sc_filters_test.test.log
for my claim about the times per format I edited
FiltersTest::testFormats and changed the loop three times to just get
three times for for FiltersTest::testFormats as if it did just one
format. Those tally fairly close to the individual format
FiltersTest::testBugFixesXX times shown above
the times are spat out to stdout, though in the gbuildified modules
output is only shown if a test fails, at the gbuild layer.
> > In an ideal world I imagine the best spent effort would be on improving
> > the import speed for .ods and .xlsx, seeing as that improves the
> > real-world case too.
> Agreed. Assuming that the files are of equivalent on-disk size.
If someone has the time, sticking basically empty .ods/.xlsx file in
there would be also worth following up. i.e. how long does loading an
empty one take :-)
It all might be a bit easier to hack some of the performance things at
the stripped-down unittest loading level. And my times are with
--enable-dbgutil, so may be totally irrelevant for real-world .ods/xlsx
loading, even if obviously relevant for dbgutil using hacking.
More information about the LibreOffice