Bug 80633 - slow dialog layout / render ...
Summary: slow dialog layout / render ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.2.4.1 rc
Hardware: Other All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:4.4.0 target:7.4.0
Keywords:
: 79185 (view as bug list)
Depends on:
Blocks: Dialog
  Show dependency treegraph
 
Reported: 2014-06-28 14:42 UTC by Michael Meeks
Modified: 2024-04-13 03:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2014-06-28 14:42:15 UTC
Launching a dialog eg. Format -> Paragraph in writer takes a noticeable time until the dialog is ready.

Running a callgrind profile on 4x of these dialog launches it can be seen that there is a lot of goodness going on.

Seemingly we have 33 bn cycles in Window::get_preferred_size
30 bn cycles from VclContainer::get_layout_requisition

with 30k calls of that - which seems quite intense.

Then again - quite probably callgrind is lying to me - the profile looks somewhat suspicious; either way - investigating.
Comment 1 Michael Meeks 2014-06-30 10:32:46 UTC
By adding some debug I get (first line is count of number of duplicate prints) - and this is for Format->Paragraph on a clean writer load:

      1 get_ungrouped_preferred size for ('7VclVBox') [0x9c01c78] -> 801, 585
      1 get_ungrouped_preferred size for ('9SwParaDlg') [0x9e3c588] -> 817, 601
      1 get_ungrouped_preferred size for ('N12_GLOBAL__N_119SvxFontSizeBox_ImplE') [0x9db0c50] -> 74, 35
      5 get_ungrouped_preferred size for ('10TabControl') [0x9ecc6a0] -> 801, 527
      5 get_ungrouped_preferred size for ('12VclAlignment') [0x9f430f8] -> 597, 87
      5 get_ungrouped_preferred size for ('13VclHButtonBox') [0x9ec98a8] -> 358, 36
...
     16 get_ungrouped_preferred size for ('9FixedText') [0x9fbbf88] -> 75, 21
     16 get_ungrouped_preferred size for ('9FixedText') [0x9fbc610] -> 47, 21
     17 get_ungrouped_preferred size for ('12VclAlignment') [0x9ecf428] -> 218, 318
     17 get_ungrouped_preferred size for ('16ImplBorderWindow') [0x9fbd3a0] -> 77, 33
...
     56 get_ungrouped_preferred size for ('9FixedText') [0x9ed2260] -> 99, 21
     56 get_ungrouped_preferred size for ('9FixedText') [0x9ed28c8] -> 82, 21
     56 get_ungrouped_preferred size for ('9FixedText') [0x9ed30e0] -> 77, 21
     74 get_ungrouped_preferred size for ('8CheckBox') [0x9f77f38] -> 182, 23
     74 get_ungrouped_preferred size for ('8CheckBox') [0x9f78688] -> 131, 23
    114 get_ungrouped_preferred size for ('9FixedText') [0x9f01a18] -> 76, 21
    225 get_ungrouped_preferred size for ('11RadioButton') [0x9f6b3b8] -> 100, 23
    225 get_ungrouped_preferred size for ('11RadioButton') [0x9f6c9f8] -> 140, 23
    225 get_ungrouped_preferred size for ('9FixedText') [0x9f6de90] -> 83, 21
    331 get_ungrouped_preferred size for ('16ImplBorderWindow') [0x9ee9198] -> 77, 33
    387 get_ungrouped_preferred size for ('16ImplBorderWindow') [0x9ee1b48] -> 135, 28
    387 get_ungrouped_preferred size for ('9FixedText') [0x9ee7bd8] -> 18, 21

One interesting thing is that the sizes seem to be always the same ie. I've not see the same widget pointer get a different size. That seems to suggest that caching the results of the sizing / text measuring here - as is done in gtk+ would be a really good idea - to prune the amount of cycles spent re-measuring text etc. Although perhaps that is already done (?) possibly something in getOptimalSize would be useful here (?).

Sadly I ran out of time to dig into this myself [ or put another way my quick-hack of a cache crashed and I lost the patch while doing something else ].
Comment 2 Commit Notification 2014-07-01 15:45:03 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7dda48d56f2d10bd6220fba19168ee1a70ecc05f

Related: fdo#80633 cache optimal size



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 3 Caolán McNamara 2014-07-01 15:55:58 UTC
How about that, does it make a difference ?
Comment 4 Commit Notification 2014-07-08 15:15:33 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=81a8f537d64acf09b2165fdbba1f8bf50b5d9ae1

Related: fdo#80633 dialog size cache has to be invalidated too



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 5 Commit Notification 2014-07-15 10:57:06 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=65ecb0d8f43f99f3794fe1aa19c87c153534fbf2

Related: fdo#80633 we can retain cached size for visibility change



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 Michael Meeks 2014-07-15 11:04:05 UTC
FWIW, I ran some tests on this (though I didn't get a callgrind trace), and there was no noticeable improvement in performance - which is really odd; there should have been ! =) but at least it goes in the right direction. Will try to run a new profile at some stage.
Comment 7 Matthew Francis 2015-01-30 02:50:44 UTC
*** Bug 79185 has been marked as a duplicate of this bug. ***
Comment 8 Yousuf Philips (jay) (retired) 2015-01-30 06:44:47 UTC
My bug was closed as a duplicate of this one, but my bug had the regression starting from 4.3 beta, while this bug is set to be a regression in 4.2.
Comment 9 Caolán McNamara 2015-01-30 11:30:33 UTC
Note that on first start, that I think then opening a dialog that this initializes the global hyphenation/word-breaking etc pile of i18n stuff which is a bit slow. So the thing to test is e.g. tools->word-count->close to initialize everything and then format->paragraph to see how slow that is. For me with a non-debugging full release build its just "there" for me so I personally don't perceive the slowdown. Probably my hardware is just too shiny.
Comment 10 Yousuf Philips (jay) (retired) 2015-02-02 17:26:46 UTC
I'm running Intel Core 2 2008 desktop and 2007 laptop, so alot of stuff is slow for me. :D
Comment 11 QA Administrators 2016-02-21 08:35:16 UTC Comment hidden (noise)
Comment 12 QA Administrators 2017-03-06 15:12:30 UTC Comment hidden (noise)
Comment 13 QA Administrators 2020-03-02 02:47:27 UTC Comment hidden (noise, obsolete)
Comment 14 Commit Notification 2022-04-13 11:45:03 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/05867c4e5f6d244f0f18db2a00e6fbc0d8141a41

tdf#80633 speed up dialog layout

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 QA Administrators 2024-04-13 03:15:14 UTC
Dear Michael Meeks,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug