Re: [Libreoffice] Proposal: slowcheck -- some numbers for sc

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[1] 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).

cd sal
edit cppunittester/cppunittester.cxx, define TIMETESTS
build
(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
FiltersTest::testRangeName: 525ms
FiltersTest::testContent: 1146ms
FiltersTest::testFunctions: 411ms
FiltersTest::testDatabaseRanges: 424ms
FiltersTest::testFormats: 1039ms
FiltersTest::testBugFixesODS: 408ms
FiltersTest::testBugFixesXLS: 61ms
FiltersTest::testBugFixesXLSX: 350ms

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.

C.