Bug 72125 - Expert config dialog takes too much time to come up
Summary: Expert config dialog takes too much time to come up
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha1
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: Confirmed:4.2.0.0.beta1:Ubuntu target...
Keywords: perf, possibleRegression
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2013-11-28 15:10 UTC by Jan Holesovsky
Modified: 2015-12-15 11:28 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
screencopy when I push the button to open the config manager (212.66 KB, image/png)
2013-12-12 15:34 UTC, Jean-Baptiste Faure
Details
backtrace when I kill the expert config dialog (16.11 KB, text/plain)
2013-12-17 07:53 UTC, Jean-Baptiste Faure
Details
MemoryUse.png (27.58 KB, image/png)
2014-01-12 12:00 UTC, pierre-yves samyn
Details
Windbg_ExpertConfig.txt (27.06 KB, text/plain)
2014-01-12 12:00 UTC, pierre-yves samyn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Holesovsky 2013-11-28 15:10:06 UTC
Tools -> Options... -> LibreOffice -> Advanced -> Expert Config Page

...and wait several seconds ;-)

Need to profile that, and ideally fix the most offending pieces there.
Comment 1 Robinson Tryon (qubit) 2013-11-30 16:49:08 UTC
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.
Comment 2 Matúš Kukan 2013-12-02 13:46:22 UTC
Find a callgrind profile for this at:
https://owncloud.documentfoundation.org/public.php?service=files&t=5aa104af60d248b0f6c342546c11dba6

(I hope it works.)
Comment 3 Noel Grandin 2013-12-06 12:27:48 UTC
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.
Comment 4 Thorsten Behrens (CIB) 2013-12-06 13:50:50 UTC
(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?
Comment 5 Commit Notification 2013-12-06 15:54:52 UTC
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.
Comment 6 Commit Notification 2013-12-06 16:08:40 UTC
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.
Comment 7 Matúš Kukan 2013-12-06 23:31:30 UTC
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.
Comment 8 Michael Meeks 2013-12-07 11:34:16 UTC
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 =)
Comment 9 Matúš Kukan 2013-12-07 14:11:19 UTC
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 ;-)
Comment 10 Commit Notification 2013-12-12 08:58:50 UTC
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.
Comment 11 Commit Notification 2013-12-12 09:00:11 UTC
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.
Comment 12 Jan Holesovsky 2013-12-12 09:02:04 UTC
Matúš: Great catch, thanks a lot!  This patch fixes that for me - I get the dialog ~instantly now.

Thanks to everyone involved!
Comment 13 Jean-Baptiste Faure 2013-12-12 15:34:26 UTC
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
Comment 14 Jean-Baptiste Faure 2013-12-12 15:39:04 UTC
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
Comment 15 V Stuart Foote 2013-12-12 16:54:38 UTC
@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
Comment 16 V Stuart Foote 2013-12-12 16:56:20 UTC
(In reply to comment #15)

> Same behavior as in bug 7046

that should have been bug 70465 of course.
Comment 17 Jean-Baptiste Faure 2013-12-12 18:16:52 UTC
(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
Comment 18 Michael Meeks 2013-12-16 20:45:18 UTC
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.
Comment 19 V Stuart Foote 2013-12-16 21:55:49 UTC
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.
Comment 20 Jean-Baptiste Faure 2013-12-17 07:53:17 UTC
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
Comment 21 Eike Rathke 2013-12-18 21:35:53 UTC
@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.
Comment 22 Jean-Baptiste Faure 2013-12-18 21:53:53 UTC
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
Comment 23 pierre-yves samyn 2014-01-12 11:59:32 UTC
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
Comment 24 pierre-yves samyn 2014-01-12 12:00:06 UTC
Created attachment 91896 [details]
MemoryUse.png
Comment 25 pierre-yves samyn 2014-01-12 12:00:40 UTC
Created attachment 91897 [details]
Windbg_ExpertConfig.txt
Comment 26 V Stuart Foote 2014-01-12 19:07:06 UTC
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
Comment 27 pierre-yves samyn 2014-01-13 09:56:00 UTC
(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
Comment 28 Robinson Tryon (qubit) 2015-12-15 11:28:12 UTC
Migrating Whiteboard tags to Keywords: (perf PossibleRegression )
[NinjaEdit]