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.
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 ].
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.
How about that, does it make a difference ?
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.
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.
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.
*** Bug 79185 has been marked as a duplicate of this bug. ***
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.
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.
I'm running Intel Core 2 2008 desktop and 2007 laptop, so alot of stuff is slow for me. :D
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.