It seems (from the callgrind regression tests) that we have a significant performance regression on master / 4.4. Unfortunately this occurred during the period the performance testing was disabled for some days - also it is not reproducible locally either - which is a doubly royal pain. It seems that: 2014-06-25 14:01:19+02:00 db960181fe63efa28c2370505b2074d1db485e07 2014-07-03 20:42:10+02:00 628520684fafb1bcbf184ab8ed2f755c6ae9ee52 2014-07-04 14:09:44+02:00 dfeef9e970a69c5736a54619b96607899c57e9a1 In this range we went from: 11086 1383415 624715 pseudo-cycles converting 032_numbers.xls-convert - which seems a very significant jump in time - 2x orders of magnitude. In this time range though the most likely candidates also look like being my fault ;-) perhaps: commit e820df579d9be4c1f9bb1ad8f02a8072c69b52da Author: Michael Meeks <michael.meeks@collabora.com> Date: Sat Jun 28 09:36:20 2014 +0100 filters: Batch fetch filter config properties. Or the patch that changes the order of configmgr keys - so that they are no longer sorted in the same order [ of course I'd -like- to think that filter configuration is independent of key sort order but ... this is the filters code ]. http://dev-builds.libreoffice.org/callgrind_report/traces/ shows that all the time (some thousand trillion cycles) is spent in the XSLT code - which (of course) shouldn't be triggered for this command: cmd: /home/buildslave/build/instdir/program/soffice.bin --splash-pipe=0 --headless --convert-to xls --outdir tmp /home/buildslave/source/test-files/loperf/032_numbers.xls Converting XLS to XLS should use native filters in each direction. Kohei - you were/are the next last person brave enough to touch the filter code =) any advice here ?
Seems its a filter selection problem; cf. aFilterName in this trace: #0 SfxObjectShell::SaveTo_Impl (this=this@entry=0x101dbe0, rMedium=..., pSet=pSet@entry=0x0) at /home/buildslave/source/libo-core/sfx2/source/doc/objstor.cxx:1124 #1 0x00007ffff562e8aa in SfxObjectShell::PreDoSaveAs_Impl (this=this@entry=0x101dbe0, rFileName="file:///home/buildslave/build/instdir/program/tmp/032_numbers.xls", aFilterName="MS Excel 2003 XML", pParams=0x137bab0, pParams@entry=0x137b320) at /home/buildslave/source/libo-core/sfx2/source/doc/objstor.cxx:2830 #2 0x00007ffff562f1cd in SfxObjectShell::CommonSaveAs_Impl (this=this@entry=0x101dbe0, aURL=..., aFilterName="MS Excel 2003 XML", aParams=aParams@entry=0x137b320) at /home/buildslave/source/libo-core/sfx2/source/doc/objstor.cxx:2689 #3 0x00007ffff5619550 in SfxObjectShell::APISaveAs_Impl (this=0x101dbe0, aFileName="file:///home/buildslave/build/instdir/program/tmp/032_numbers.xls", aParams=aParams@entry=0x137b320) at /home/buildslave/source/libo-core/sfx2/source/doc/objserv.cxx:314 #4 0x00007ffff5663807 in SfxBaseModel::impl_store (this=this@entry=0x7fffe1d92b30, sURL="file:///home/buildslave/build/instdir/program/tmp/032_numbers.xls", seqArguments=uno::Sequence of length 2 = {...}, bSaveTo=bSaveTo@entry=true) at /home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:3064 #5 0x00007ffff5664f7d in SfxBaseModel::storeToURL (this=0x7fffe1d92b30, rURL="file:///home/buildslave/build/instdir/program/tmp/032_numbers.xls", rArgs=uno::Sequence of length 2 = {...}) at /home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:1701 #6 0x00007ffff574afbb in desktop::DispatchWatcher::executeDispatchRequests (this=0x7fffe3d65a90, aDispatchRequestsList=std::vector of length 1, capacity 1 = {...}, bNoTerminate=<optimized out>) at /home/buildslave/source/libo-core/desktop/source/app/dispatchwatcher.cxx:495 #7 0x00007ffff5751982 in desktop::OfficeIPCThread::ExecuteCmdLineRequests (aRequest=...) at /home/buildslave/source/libo-core/desktop/source/app/officeipcthread.cxx:1060 #8 0x00007ffff5737612 in desktop::Desktop::OpenClients () at /home/buildslave/source/libo-core/desktop/source/app/app.cxx:2442 #9 0x00007ffff5738350 in desktop::Desktop::OpenClients_Impl (this=0x7fffffffdc60) at /home/buildslave/source/libo-core/desktop/source/app/app.cxx:1975 #10 0x00007ffff63b844a in Call (pCaller=<optimized out>, this=<optimized out>) at /home/buildslave/source/libo-core/include/tools/link.hxx:139 #11 ImplHandleUserEvent (pSVEvent=0xf70d70) at /home/buildslave/source/libo-core/vcl/source/window/winproc.cxx:1921 #12 ImplWindowFrameProc (pWindow=<optimized out>, nEvent=<optimized out>, pEvent=0xf70d70) at /home/buildslave/source/libo-core/vcl/source/window/winproc.cxx:2492 #13 0x00007ffff665d926 in CallCallback (pEvent=<optimized out>, nEvent=<optimized out>, this=<optimized out>) at /home/buildslave/source/libo-core/vcl/inc/salframe.hxx:243 #14 SvpSalInstance::Yield (this=0x6c5130, bWait=<optimized out>, bHandleAllCurrentEvents=<optimized out>) at /home/buildslave/source/libo-core/vcl/headless/svpinst.cxx:293 #15 0x00007ffff6585b8e in ImplYield (i_bAllEvents=false, i_bWait=true) at /home/buildslave/source/libo-core/vcl/source/app/svapp.cxx:360 #16 Application::Yield () at /home/buildslave/source/libo-core/vcl/source/app/svapp.cxx:392
#6 0x00007ffff574afbb in desktop::DispatchWatcher::executeDispatchRequests (this=0x7fffe3d65a90, aDispatchRequestsList=std::vector of length 1, capacity 1 = {...}, bNoTerminate=<optimized out>) at /home/buildslave/source/libo-core/desktop/source/app/dispatchwatcher.cxx:495 (gdb) p conversionProperties $8 = uno::Sequence of length 2 = {{Name = "Overwrite", Handle = 0, Value = uno::Any 1 '\001', State = com::sun::star::beans::PropertyState_DIRECT_VALUE}, {Name = "FilterName", Handle = 0, Value = uno::Any "MS Excel 2003 XML", State = com::sun::star::beans::PropertyState_DIRECT_VALUE}} ... Seems like dispatchwatcher.cxx's: static OUString impl_GuessFilter( const OUString& aUrlIn, const OUString& aUrlOut ) { /* aAppl can also be set to Factory like scalc, swriter... */ OUString aAppl; aAppl = impl_GetFilterFromExt( aUrlIn, SFX_FILTER_IMPORT, aAppl ); return impl_GetFilterFromExt( aUrlOut, SFX_FILTER_EXPORT, aAppl ); } is getting a sillier than expected results =)
Looks like the problem is in the ordering of filters here: #0 filter::config::FilterCache::detectFlatForURL (this=0xf74d30, aURL=..., rFlatTypes=empty std::list) at /home/buildslave/source/libo-core/filter/source/config/cache/filtercache.cxx:744 744 for (OUStringList::const_iterator pIt = rTypesForExtension.begin(); ... (gdb) p rTypesForExtension $23 = (const filter::config::OUStringList &) @0xf91408: {<std::vector<rtl::OUString, std::allocator<rtl::OUString> >> = std::vector of length 5, capacity 8 = {"calc_MS_Excel_2003_XML", "calc_MS_Excel_5095", "calc_MS_Excel_95", "calc_MS_Excel_40", "calc_MS_Excel_97"}, <No data fields>} Of course - it would be hard to believe that this ordering is based on some un-controlled / random sort order - surely !?
@Michael: There is a similar issue in Bug 78989. It seems to return different results on different systems.
(In reply to comment #3) > Of course - it would be hard to believe that this ordering is based on some > un-controlled / random sort order - surely !? This does not matter for save/export dialogs, as these always set an exact filter type. So I suppose nobody cared (or noticed) till now.
David Tardon committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=24d20bce789063f6dba2df1c5d2c5a8948d24370 fdo#80955 make calc_MS_Excel_97 filter default for xls ext. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
There is a way to set a filter as "preferred" for a given extension. But it had not been used for the filters associated with 'xls'.
(In reply to comment #0) > It seems (from the callgrind regression tests) that we have a significant > performance regression on master / 4.4. ^^^^^^^^^^^^ I'll set the version field per Michael's comment.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0f8cf397d4de28ab9e16d4d1c6ca408323d7e189 fdo#80955 - add a unit test. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.