Created attachment 107496 [details] Document That Is Very Slow with LO 4.3 We have upgraded from 4.2 to 4.3 and found that documents with form controls are too slow to use. When you file > open this document, it chews 100% of the CPU and opens very slowly and once open, you can barely navigate through it. My research indicates: LibreOffice 4.2 works correctly LibreOffice 4.3 is too slow to use LibreOffice 4.4 (Alpha) is too slow to use Test was performed on Linux platform. We have 100 employees that use these documents and they are not able to perform this task with LO 4.3.
Closing, found an issue for further testing here.
reopening, and marking unconfirmed.
Thanks for the report Dave. I confirm the problem and see it already from 4.3.0 aplha1 (No pun intended: but some of you would have the opportunity to run some greedy documents in alpha or beta versions :) would be great!) Sine I run Linux, same as you, I set platform accordingly. Regards, Cor
I just re-tested with LO Master (4.4) dated Oct-07-2014 and it's got the same issue, so it appears that moving users to a beta or alpha release will not help. Going to try and nominate for MAB as it meets this criteria.
(In reply to Dave Richards from comment #4) > I just re-tested with LO Master (4.4) dated Oct-07-2014 and it's got the > same issue, so it appears that moving users to a beta or alpha release will > not help. No not now. But testing early does help finding problems early. Thanks for confirming on the 4.4 master! > Going to try and nominate for MAB as it meets this criteria. Fair enough.
Hi Dave - in the future please don't nominate your own bugs to the MAB list. We're simply too biased about our own bugs to be objective about the process. If you think that you're bug should be on the list - email the QA mailing list and ask for someone else to check it out. That being said - I disagree with MAB status BUT I won't remove it. What you could do to help is do a bibisect (usually this is a requirement for MAB bugs that are regressions) https://wiki.documentfoundation.org/QA/HowToBibisect The download is 11+ gigs but the steps are pretty straight forward and it'll help us get to a solution. Thanks
@joel, very fair of you thank you. The steps for MAB has changed apparently, I'm sorry. I have added my own bugs in the past, but certainly understand that everyone feels their own bugs are important :) In this case, LO really is not functional with these documents...made even worse by the fact that it's an ODT. I will make some time to learn how to bibisect and reproduce. We have a spare Ubuntu server with enough horsepower to compile easily.
Yeah I need to update that MAB wiki page - there are just a couple basic points: 1) don't put your own bugs on there 2) Set importance to highest 3) The comment on the tracker - which you did do :) 4) For regressions if at all possible get a bibisect to help our overloaded devs resolve the problem faster. Bibisect takes about 10-15 minutes, you can learn it in half hour or less but the download is massive. Basically you just test the bug 10-12 times and it tests it against about 755 builds and helps to narrow the regression down to about 50-100 commits which makes it relatively easy to locate where things went wrong. If you do learn how to do it - feel free to try to bibisect some of the other regressions floating around ;) We have about 250 or so bugs that could use bibisecting but only have a half dozen or so people doing them and only sporadically as they can be a bit time consuming. Thanks for the understanding! Good luck with bibisecting. Feel free to come say hello to us in the chat: webchat.freenode.net/?channels=libreoffice-qa
@joel, I already am on that channel every day 8-5 eastern time (dave_largo). I work for the City of Largo, we have 800+ employees on LibreOffice. I should be able to get my head around it and try and grab a few more of them to assist.
Bibisect results from 43only - testing on the basis of whether or not the document was usable immediately on load There are only 'skip'ped commits left to test. The first bad commit could be any of: a078c448818ec92dcfa83d83c741763c454a844c a752c485722c3344d88b1dfc7ea5f69c56597c9e 91072c3aa6480077f7587e803cecfa727270a2ea We cannot bisect more! $ git bisect log git bisect start # good: [6ab7f53af36f13bbefdd4e4fcbd3d1ea432a77d9] source-hash-22029c7e17b4cb48acb058d47ec9c3b6b8b6b294 git bisect good 6ab7f53af36f13bbefdd4e4fcbd3d1ea432a77d9 # bad: [a92705c1fabafddd43d175a0714855cd22551232] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect bad a92705c1fabafddd43d175a0714855cd22551232 # bad: [bebf9d31c8fe9de96798484288a0fffc4d54917d] source-hash-09e5de8278dd8f13adcf614db35c8a8a04ba8e47 git bisect bad bebf9d31c8fe9de96798484288a0fffc4d54917d # bad: [20d42d26a12e5ded00b3510d2d9e254e7876dc78] source-hash-c1503da35d8879366da13258837cf0084a536809 git bisect bad 20d42d26a12e5ded00b3510d2d9e254e7876dc78 # good: [df997ea92f012344541d1cf25eb1ff402e6de210] source-hash-7f5494f3c4bf14209a119c6b21c02e10075503ae git bisect good df997ea92f012344541d1cf25eb1ff402e6de210 # good: [2efdfdeffbeb25fedb9a63c5d0e3168e03349f24] source-hash-d1ba55a28cd40134356faf3e01971491086591d9 git bisect good 2efdfdeffbeb25fedb9a63c5d0e3168e03349f24 # bad: [1bcf9fe42f3009920b180819ada17589b453486a] source-hash-d803483f6a5938b0d0708b8db74b30c511dd8e31 git bisect bad 1bcf9fe42f3009920b180819ada17589b453486a # skip: [a078c448818ec92dcfa83d83c741763c454a844c] source-hash-6069b5162281ccc88eb242991a115197d0893fb4 git bisect skip a078c448818ec92dcfa83d83c741763c454a844c # bad: [91072c3aa6480077f7587e803cecfa727270a2ea] source-hash-78a61583c266a1fd222cd78c912e35e93f7010d3 git bisect bad 91072c3aa6480077f7587e803cecfa727270a2ea # skip: [a752c485722c3344d88b1dfc7ea5f69c56597c9e] source-hash-03725013b64e74473e1a9e925b24927e7e61d412 git bisect skip a752c485722c3344d88b1dfc7ea5f69c56597c9e # good: [79c7c3f8bd24f25fe0d0d3abc3fc7e9006cee014] source-hash-ed5065d8b080bfaf51ea1232cebf3ff72af1e640 git bisect good 79c7c3f8bd24f25fe0d0d3abc3fc7e9006cee014 # only skipped commits left to test # possible first bad commit: [91072c3aa6480077f7587e803cecfa727270a2ea] source-hash-78a61583c266a1fd222cd78c912e35e93f7010d3 # possible first bad commit: [a078c448818ec92dcfa83d83c741763c454a844c] source-hash-6069b5162281ccc88eb242991a115197d0893fb4 # possible first bad commit: [a752c485722c3344d88b1dfc7ea5f69c56597c9e] source-hash-03725013b64e74473e1a9e925b24927e7e61d412
Follow-up source bisect points at the following commit: 1615b7f1d078b2bdf22a856066346e701f816b72 is the first bad commit commit 1615b7f1d078b2bdf22a856066346e701f816b72 Author: Khaled Hosny <khaledhosny@eglug.org> Date: Fri Jan 17 01:57:03 2014 +0200 Do proper script itemization with HarfBuzz This implements http://www.unicode.org/reports/tr24/ by using ICU’s implementation of it, but since the code in question is private API, I simply copied the two self-contained files. This commit is best viewed with --ignore-space-change. Change-Id: I38c385d4fb6f8a2edc804d48f0aa14df9f0a8b3b :040000 040000 d9cb908c60ef7bf79b68d585bd63d92f4a0e1e6e da6b70c25dadade9f2500c57a820281da9ec3319 M vcl $ git bisect log git bisect start # bad: [78a61583c266a1fd222cd78c912e35e93f7010d3] Minor update for Raspbian git bisect bad 78a61583c266a1fd222cd78c912e35e93f7010d3 # good: [03725013b64e74473e1a9e925b24927e7e61d412] bool improvements git bisect good 03725013b64e74473e1a9e925b24927e7e61d412 # skip: [6069b5162281ccc88eb242991a115197d0893fb4] more build fixes git bisect skip 6069b5162281ccc88eb242991a115197d0893fb4 # bad: [8db51361dc199c731cb82a06f90b4d2ff8eebfaf] coverity#1132662 Dereference after null check git bisect bad 8db51361dc199c731cb82a06f90b4d2ff8eebfaf # bad: [72b5343bd16deec540d8cd148cd7aebd74e92c16] fwk: Use constructor feature for ModuleUIConfigurationManager. git bisect bad 72b5343bd16deec540d8cd148cd7aebd74e92c16 # bad: [718329232eac6bd2c1e5f46f9c49dbec289c2b86] This is an int, not float git bisect bad 718329232eac6bd2c1e5f46f9c49dbec289c2b86 # good: [b1e1ab577fe7f402a5367a624963338a1dbf6a55] Follow-up (micro-?)optimisation git bisect good b1e1ab577fe7f402a5367a624963338a1dbf6a55 # good: [5e6d1e3332ea4cd31d2c5e739dc27bb37b34b4dc] Replace deprecated std::auto_ptr with boost::scoped_ptr git bisect good 5e6d1e3332ea4cd31d2c5e739dc27bb37b34b4dc # bad: [1615b7f1d078b2bdf22a856066346e701f816b72] Do proper script itemization with HarfBuzz git bisect bad 1615b7f1d078b2bdf22a856066346e701f816b72 # good: [97ed0bdcb283a3c45d4b155515cd9ef5d97138ab] Use a more descriptive and distinct field name git bisect good 97ed0bdcb283a3c45d4b155515cd9ef5d97138ab # first bad commit: [1615b7f1d078b2bdf22a856066346e701f816b72] Do proper script itemization with HarfBuzz
The attached document also produces a probably unrelated crash on 4.4 master - raised separately on bug 85032
IMO now that we have a fix for bug #85032 the underlying problem there is the same as the one here. Except that instead of crashing the 65k long effectively randomly filled string is incredibly expensive to process for script changes. After the change the string is property empty so the problem doesn't arise. https://gerrit.libreoffice.org/#/c/11985/ for 4-3
*** Bug 61270 has been marked as a duplicate of this bug. ***
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3-3&id=a16d55f9b0207dadf96c41a1581a649e67a921ad
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]