Description: Comparing releases 5.2.3 and 5.2.4 somewhere in fixes between those versions big perfomance regression was introduced when opening certain xlsx files (created by excel). I cannot include file here since it's business related, but I will send it to QA email when requested. Steps to Reproduce: Just open file, from windows explorer or LibreOffice start menu, it doesn't matter. Actual Results: LO 5.2.4. file opening: 1st opening: 1:39:82 2nd opening: 0:15:39 3rd opening: 0:15:14 1st opening of another similliar file, without restarting computer, after all test above: 0:15:84 If I restart computer and try to open this file first: 1:39:21 Expected Results: LO 5.2.3. file opening: 1st opening: 0:06:55 2nd opening: 0:04:93 3rd opening: 0:05:18 1st opening of another similliar file, without restarting computer, after all test above: 0:06:16 Reproducible: Always User Profile Reset: No Additional Info: Conclusion: First opening of file take extremly long, 15x times longer then with 5.2.3. release. But after file was opened first time, until reboot, you can open same file and all similliar files much faster, but still 3x times slower then with 5.2.3. release. User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Searching for fixed which could have introduced it and without bibisect we will not know for sure, but bug 79892 feels like a good candidate.
Hm, that's interesting... If you're fine with e-mailing the file to me, I can take a look. Otherwise I'd suggest sanitizing the data. What's the system locale?
Link sent on your email. Windows 8.1, system locale HR (croatian), LO UI croatian. LO 5.2.3. testing was done with portable US locale version.
# bad: [479ca41474b9720803421ab7717aa69fa6c60528] source f8c463b393885b660500bf4f7f73b4fb90ce2389 # good: [defb73f1c6e2a66dbd21ba89e684f57427e8bc4b] source 5b168b3fa568e48e795234dc5fa454bf24c9805e git bisect start '479ca41474b9720803421ab7717aa69fa6c60528' 'oldest' # good: [1c50425620ffbce30bb57f9ff19ef3c5d20d69f1] source b62f4c2cd9685618fff2270760ce0787880f1c8d git bisect good 1c50425620ffbce30bb57f9ff19ef3c5d20d69f1 # good: [70770f0ce4d3672d5cd2759605adb44d867e7208] source 0b7e11a2a7ade0b565c18d1deb58c19848f6ceef git bisect good 70770f0ce4d3672d5cd2759605adb44d867e7208 # bad: [ce5c761b06e108ba3a25fccda8acb9d3c2aedaba] source ea6b378221efea0392c5085d621ff38a612ade3e git bisect bad ce5c761b06e108ba3a25fccda8acb9d3c2aedaba # good: [b8c8947e0cba99aac490ddfd4d148868f7380ddc] source 34dc5ea5510df5692addbf4d8559e72085a4835b git bisect good b8c8947e0cba99aac490ddfd4d148868f7380ddc # bad: [cc6341b021166bdafe3923880e2ce3deaa94982f] source 5aa43c380a14869c03525396757debbddb602b44 git bisect bad cc6341b021166bdafe3923880e2ce3deaa94982f # bad: [50ca7c2dec19f05db0208251ff4e0ea07ff975cb] source 5d5564fa7ac77303e6e6145e488bc28bc675a860 git bisect bad 50ca7c2dec19f05db0208251ff4e0ea07ff975cb # good: [a7a02c48aabed896a8d54852040a37a5dce9d103] source 578e890e89c9a143d36b3d7307dcdc0545523614 git bisect good a7a02c48aabed896a8d54852040a37a5dce9d103 # bad: [ad8fcfd29fef48a963333e4291b121c2e7a184a7] source 12127e1eaf63fec008cba3fe705e23ba86a704f7 git bisect bad ad8fcfd29fef48a963333e4291b121c2e7a184a7 # good: [c1377006a8c90551f73c3c1eb77db152d0680601] source 01b5dfb418f4e0d98b605cb21fd0175601da5a9d git bisect good c1377006a8c90551f73c3c1eb77db152d0680601 # bad: [3550ace0daedb90180dccde4000bc2a5fe38e26d] source 8175e30b732e3f6f4f1058934e7fe8a1189f40cf git bisect bad 3550ace0daedb90180dccde4000bc2a5fe38e26d # good: [da5d9fd6c14500b325552f4d3d62f4d73baa5582] source 36e390eaa55ae302dc5a64fa7098ec43e2009748 git bisect good da5d9fd6c14500b325552f4d3d62f4d73baa5582 # bad: [1c4681006513b894800530c8706535384a90a27c] source a3b3e336e5bd83754d9caae85dd5b9246bb4f7c1 git bisect bad 1c4681006513b894800530c8706535384a90a27c # bad: [cfc6cbaeeb78bab8c91a4e19b8e0e09beca134ef] source 8464ea6961b9cc54af9c11cce1b80ed7e0cc77e2 git bisect bad cfc6cbaeeb78bab8c91a4e19b8e0e09beca134ef # first bad commit: [cfc6cbaeeb78bab8c91a4e19b8e0e09beca134ef] source 8464ea6961b9cc54af9c11cce1b80ed7e0cc77e2 commit cfc6cbaeeb78bab8c91a4e19b8e0e09beca134ef Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Oct 25 22:51:17 2016 -0700 source 8464ea6961b9cc54af9c11cce1b80ed7e0cc77e2 source 8464ea6961b9cc54af9c11cce1b80ed7e0cc77e2
I can confirm the regression. From start to the time when I get a dialog about updating external files the times are these (OS: Windows 7): -5.2.3.3: 6s, -5.2.4.2: 29s, then 24s next time. Bug could be bibisected, and the bug is caused by the commit below. Adding Cc: to Eike Rathke. Please take a look. It's up to Mikeyy to share the bugdoc. https://cgit.freedesktop.org/libreoffice/core/commit/?id=8464ea6961b9cc54af9c11cce1b80ed7e0cc77e2 "Resolves: tdf#79442 in OOXML import add external files to LinkManager Now that we store formula results without recalculating, the implicit logic that adds files of external references to the LinkManager is not triggered, explicitly force it during import."
The file contains 11 external references, which point to network resources. For those this line (and basically the underlying system routine) takes up a long time: if (osl::DirectoryItem::get(GetName(), item) == osl::FileBase::E_None) { http://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx#2608
Created attachment 130427 [details] New test file Managed to find small file which I could clean up in code. It probably has less connections then first test file so it takes "only" 48 seconds to open this file in LO 5.2.4, while it takes 3 seconds to open it in LO 3.3
External links point to Samba shares, setting up the link tries to access the file content to detect the filter to use, which for each file has to wait for the timeout if the share is not mounted.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=416752b9e4bc4605c479d3eff7797be9f0ef2a38 Resolves: tdf#104875 defer filter detection to first load/update of external It will be available in 6.0.0. 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.
Pending review https://gerrit.libreoffice.org/38819 for 5-4 https://gerrit.libreoffice.org/38820 for 5-3
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d6797cde0663f3a558568a26ad19c7b5c98efa7&h=libreoffice-5-4 Resolves: tdf#104875 defer filter detection to first load/update of external It will be available in 5.4.0.1. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4175045ebe4c895ff4617fbcdaacbbb058751597&h=libreoffice-5-3 Resolves: tdf#104875 defer filter detection to first load/update of external It will be available in 5.3.5. 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.