Tools -> Options... -> LibreOffice -> Advanced -> Expert Config Page ...and wait several seconds ;-) Need to profile that, and ideally fix the most offending pieces there.
CONFIRMED on LO 4.2.0.0.beta1 + Ubuntu 12.04.3 (In reply to comment #0) > Tools -> Options... -> LibreOffice -> Advanced -> Expert Config Page > > ...and wait several seconds ;-) I waited for 2 minutes, and finally killed the process. > > Need to profile that, and ideally fix the most offending pieces there. When was this feature introduced? I checked 4.1.2.3 to see if I could track down the regression point, but it appears that it post-dates that build.
Find a callgrind profile for this at: https://owncloud.documentfoundation.org/public.php?service=files&t=5aa104af60d248b0f6c342546c11dba6 (I hope it works.)
I've done some basic analysis of this, but I find KCacheGrind hard to follow, so take this with a pinch of salt: My preliminary conclusion is that SvTreeListBox is simply not designed for this number of elements. It appears to be doing a calculation of item height for every single item inserted, which is generating a ton of calls down into the text layout subsystem, which is adding up to a lot of time. A stripped down stack trace looks like: SvxJavaOptionsPage::ExpertConfigHdl_Impl ->CuiAboutConfigTabPage::Reset ->CuiAboutConfigTabPage::FillItems ->CuiAboutConfigTabPage::InsertEntry ->SvHeaderTabListBox::Insert ->SvTreeListBox::Insert ->SvListView::ModelNotification ->SvTreeListBox::InitViewData ->SvLBoxString::InitViewData ->OutputDevice::GetTextWidth Other ListBox implementations handle this one of two ways: (a) the client code explicitly specify the row height, and the ListBox just uses that number, not calling any text layout (b) the ListBox assumes that all rows are the same height and only calls layout for the first row.
(In reply to comment #3) > Other ListBox implementations handle this one of two ways: > (a) the client code explicitly specify the row height, and the ListBox just > uses that number, not calling any text layout > (b) the ListBox assumes that all rows are the same height and only calls > layout for the first row. > Matches my earlier poking. Can we not stick an extra flag to the TreeList, forcing one of the above behaviours?
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7468f9b773d5a9a4cb3af57cf123c2a0e7e937fd fdo#72125 - Expert config dialog takes too much time to come up 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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a176f564883b3bfd16fbf1750d46521d4a491dc2&h=libreoffice-4-2 fdo#72125 - Expert config dialog takes too much time to come up It will be available in LibreOffice 4.2. 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.
I did not study what your commit does, but please check new profile: https://owncloud.documentfoundation.org/public.php?service=files&t=786e839225899a0a4cf303db8ff6b448 And please revert or fix your commit. Or verify I am mistaken. It should make it ~50% slower in fact. For some reason, we are now calling that InsertEntry 34k times - Is it possible ? I might check your patch later too. I've applied 7468f9b773d5a9a4cb3af57cf123c2a0e7e937fd bd8b3be0c7535e74ca8b63969be5c2bece0d3a3b 434465cee3c5e21881d3466f115d968e8fbf731c before making the new profile.
Matus - it is entirely likely that we have 34k items =) Our configuration data is rather <cough> significant in size =) $ xmllint --format share/registry/main.xcd | grep '<prop' | wc -l 13453 eg. ;-) FWIW, the gtk+ treeview has exactly this same problem - and what it does is to have a mode where we assume that all rows are the same fixed height - which saves an infinite test measuring cost =) http://www.gtk.org/api/2.6/gtk/GtkTreeView.html#gtk-tree-view-set-fixed-height-mode Has the docs there - it's used in eg. e-mail views. I imagine we need to provide a similar feature and/or enable it if it is there already =) I don't see another way to avoid the cost of text measuring =)
Ok, so 7468f9b773d5a9a4cb3af57cf123c2a0e7e937fd fixes the dialog but not this bug - it makes the dialog slower. Before there were ~25k items - so some of them were missing. I don't understand how - only change I see is that we no longer use XHierarchicalNameAccess there - so that's it, I guess? Anyhow, it does not matter. Also - height is not a problem, width is. OutputDevice::GetTextWidth ~9328 m CEst OutputDevice::GetTextHeight ~6 m CEst I've "fixed" it in svtools/source/contnr/svlbitm.cxx SvLBoxString::InitViewData: - pViewData->maSize = Size(pView->GetTextWidth(maText), pView->GetTextHeight()); + pViewData->maSize = Size(10, pView->GetTextHeight()); That makes it fast. That's of course wrong, but it shows that we ignore width for first 3 columns, so no need to compute it. Proper fix is to avoid this. And if it's still slow, we can also set fixed width for 4th column. I am not volunteering, I tried to look into it but it would take me at least day or two to understand the details a bit more. Hope this helps ;-)
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62ea355b2679073b8ee326df5793231996136da9 fdo#72125: GetTextWidth() can get very expensive. 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.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e6ce9e2102a923bd0dab0b791db3587c6e434f2&h=libreoffice-4-2 fdo#72125: GetTextWidth() can get very expensive. It will be available in LibreOffice 4.2. 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.
Matúš: Great catch, thanks a lot! This patch fixes that for me - I get the dialog ~instantly now. Thanks to everyone involved!
Created attachment 90669 [details] screencopy when I push the button to open the config manager It does not work for me with Version: 4.2.0.0.beta2+ Build ID: be366ad7690b190c5ef4dc42311a4df6b7dcce4b) under Ubuntu 13.10 x86-64. even with a clean new user profile. Best regards. JBF
Additional information: there is perhaps a memory leak. Indeed LO 4.2 does not really freeze, it is occupied to eat the RAM. Best regards. JBF
@JBF (In reply to comment #14) > Additional information: there is perhaps a memory leak. Indeed LO 4.2 does > not really freeze, it is occupied to eat the RAM. > Do you by chance have an Assistive Technology enabled, ORCA perhaps? I am on Windows 7 sp1, 64-bit system with Version: 4.3.0.0.alpha0+ Build ID: 7bf2f528ef22f50aa167ba57f2e25d4452977060 TinderBox: Win-x86@39, Branch:master, Time: 2013-12-12_09:44:32 Without an Assistive Technology AT active -- now seeing "Expert Config" page populate in about 2 seconds. Orders of magnitude faster. However with AT (NVDA 2013.2) active launching the "Expert Config" results in non-responsive LibreOffice, with memory use growing into the 710 KB of Private Working Set Memory and i7 CPU use at 13% for 13 minutes--with only 205 handles and 7 threads. The treeview finally completes! Same behavior as in bug 7046 -- I am thinking there might be unresolved XAccessibility events being fired in building the TreeView. Stuart
(In reply to comment #15) > Same behavior as in bug 7046 that should have been bug 70465 of course.
(In reply to comment #15) > [...] > Do you by chance have an Assistive Technology enabled, ORCA perhaps? No, nothing like that. Expert Config Page worked slowly but worked for me when it was not yet in a subpage launched from a button. Best regards. JBF > > I am on Windows 7 sp1, 64-bit system with > > Version: 4.3.0.0.alpha0+ > Build ID: 7bf2f528ef22f50aa167ba57f2e25d4452977060 > TinderBox: Win-x86@39, Branch:master, Time: 2013-12-12_09:44:32 > > Without an Assistive Technology AT active -- now seeing "Expert Config" page > populate in about 2 seconds. Orders of magnitude faster. > > However with AT (NVDA 2013.2) active launching the "Expert Config" results > in non-responsive LibreOffice, with memory use growing into the 710 KB of > Private Working Set Memory and i7 CPU use at 13% for 13 minutes--with only > 205 handles and 7 threads. The treeview finally completes! > > Same behavior as in bug 7046 -- I am thinking there might be unresolved > XAccessibility events being fired in building the TreeView. > > Stuart
I strongly suspect that JBF has Accessibility enabled in some way. These huge widgets need special support to be MANAGES_DESCENDANTS widgets, and even then it's really not a good solution: better is to expose only the visible widgets. I'd love to close this out - it's almost certainly an a11y related issue. So - instead of re-opening, can we split a bug with the a11y details included.
On Windows 7 sp1, 64-bit on an Intel Core2 6400 @ 2.13 GHZ Version: 4.2.0.0.beta2+ Build ID: d663228bd348c844f38914c9e2167ef01fadf3b3 TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2013-12-14_23:15:05 Get very fast Expert config now with AT disabled. But with AT support (NVDA 2013.2) and IAccessible2 based support enabled, launching Expert Config sends CPU usage rocketing running up CPU usage for both LibreOffice and the AT. With IAccessible2, get a viable expert config table in about 6 minutes -- nicely configured as an IA2 table, with cells containing IA2Accessibletext in a ia2 role of tableCell, mass accName of cell value and accRole of tableCell. With AT support (NVDA 2013.2) and Java Accessibility Bridge based support, launching Expert Config runs soffice.bin CPU usage up 47-48% ranges. NVDA also runs into very high usages 38-41%, but the soffice.bin/soffice.exe crash before the expert-config table is generated. Guess it would be OK to close this issue resolved fixed, and move the AT related table build issue back to the bug 70465.
Created attachment 90864 [details] backtrace when I kill the expert config dialog I do not know how to check if I have accessibility enabled on my Ubuntu 13.10. Here is a backtrace obtained in a gdb session just after I killed LO when it freezes on opening the expert config dialog. I read the word accessibility in this bt, is the problem there? I do not know if I can deactivate accessibility in autogen.input Best regards. JBF
@Jean-Baptiste: Accessibility (a11y) is not a build option, it is a runtime behavior that depends on your operating system's settings (e.g. screen reader enabled, or on recent systems the general a11y support, i.e. in Gnome which likely is enabled on your Ubuntu). If a11y is enabled in the system then LO does all that's required to feed the a11y API. However, the Java a11y bridge could be disabled using configure --without-java that disables support for all Java components.
Hi Eike, thank you for these informations. I disabled all a11y functionalities I could find on my PC, in system parameters and in Compiz config. Orca is installed but not used. I did some more tests: - I have the same problem with the beta-2 build by TDF - on another PC with Xubuntu 13.10 x86-64 but under an Unity session, I do not have the problem with the beta-2 from TDF. - I did a build with option --with-java=no and that did not fix the problem. Best regards. JBF
Hello I reproduce on windows 7/64 with Version: 4.2.0.2 Build ID: cd65d6220c5694ee7012d7863bcde3455c9e3c30 Steps to reproduce: 1. Launch LibreOffice 2. Tools> Options> LibreOffice> Advanced> Expert config. The dialog never opens. Memory grows up to 1450920K (see MemoryUse.png) You have to kill the process. I join a bt (see Windbg_ExpertConfig.txt) Note: I do *not* reproduce on the same PC with Version: 4.3.0.0.alpha0+ Build ID: ae8e579515fff84cbef1ccc2da78fa769fb079ec TinderBox: Win-x86@39, Branch:master, Time: 2014-01-10_11:16:31 The dialogs opens after 2 seconds. Regards Pierre-Yves
Created attachment 91896 [details] MemoryUse.png
Created attachment 91897 [details] Windbg_ExpertConfig.txt
Pierre-Yves (In reply to comment #23) Suspect you have support for assistive technologies checked active. As a result Efe's Expert Config builds the tables with XAccessible elements which is extremely slow. We've moved that issue to its own issue of bug 70465, where your results are consistent. I've added you the the CC there. Stuart
(In reply to comment #26) > Suspect you have support for assistive technologies checked active. Thank you for this suggestion. I do not know how to check it reliably with windows 7... The fact that I can not reproduce the problem on the same computer with version 4.3.0.0.alpha0+3, is it consistent with this explanation? Regards Pierre-Yves
Migrating Whiteboard tags to Keywords: (perf PossibleRegression ) [NinjaEdit]
please check Bug 109158 - slower loading of a huge AutoCorrect replacement table the fix for current Bug 72125 seems to have introduced a performance regression in the autocorrect replacement table loading (this is what is suggested by bibisect results).