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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
