This one is a spin off from "Bug 52080 - Large files become unresponsive since version 3.5.0". The main problem has become WORKSFORME, but there still exist performance problems. Steps how to reproduce [Reproducible] with parallel installation of "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch: 1. From LibO Start Center open Attachment 64199 [details] for Bug 52080 2. Scroll to last page 3. try to select several words by double click quickly one after the other. Problem: It always takes 2 seconds until the word becomes highlighted Of course such a 6000 pages document is a hard nut, but that worked without visible delay with LibO 3.3.3
The exact same delay is also seen when scrolling back & forth in the document and when zooming in & out. This part of it is a regression from 3.6.4. Delays when selecting text were present since 3.5 but improved significantly with 3.6.3 & 3.6.4 although it still renders the application unusable since it takes about 7 or 8 seconds on my 3GHz Quad-core computer for it to become responsive again.
I did some more testing. I think the delay in zooming and scrolling only occurs when text is selected
If the problem does not seem to be ocurring in the test document then try turning on the page headers & footers. Now click & hold the left mouse button in the header area and drag the mouse down the document window to select text. From then on the delay should be noticed. This caused the delay for me in larger documents which at first seemed to behave normally.
Just a note in case it makes a difference. I am running this on Ubuntu 12.10 64bit using KDE plasma.
@David: Your really think that a problem of a single user with an exotic 6000 pages Writer document will be seen as a critical Problem for the LibO project? That's not a realistic assessment.
This is not a simple "very large document" problem. I tried a 8835 pages lorem ipsum document, works without problems with "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch. @David Any idea what special thing in your document might cause the problem? Currently I do not understand your header/footer experiment.
Well it's critical enough for me that I've been unable to upgrade ever since 3.5.0 (although with 3.6.3 & 3.6.4 there has been improvement). I'm becoming more and more convinced that it has something to do with the new way the headers & footers are handled or the way pages are handled because of the new header & footer routines since that is one thing which had a major change in 3.5.0 and in testing there seems to be some corralation. I have several large documents which have MANY character & paragraph style changes throughout the document and also uses a couple of different page styles. These files work perfectly in 3.4.6 and prior. Performance is quick and I notice no lag time at all. The documents I have (other than the sample document) that exhibit this problem run about 3000 pages. The test document always has a long delay when selecting text. But some files I have only have the lag after I click in the header and then click somewhere else in the document. After I wrote that other message I found that I didn't actually need to select text but that just clicking in the header would cause the delays to begin and I would need to close the document and re-open it.
At least my lorem ipsum document caused a hang when I activated headers / footers, may be that's really related. I'll do further tests tomorrow
And with Attachment 64199 [details] the problems become much bigger when I activate page header / footer (after I have had seen caret in header the first time). I reduced increased number of pages (more than 7000 after enabled H/F) to 5900, the selection problems remain much worse than in Step 3 of original report. There it takes 2s starting with the second selection, with headers/footer 15s. After Disabled H/F back to 2s. (parallel installation of "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch 64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430,
While I managed to start the app in callgrind and load the document (eventually) - after that callgrind wedged: it is quite a big ask I guess, so I didn't even get a load profile; nevermind being able to examine the exact slow piece. Will try with manual gdb / sampling instead.
Looks like a pretty horrible N^2 algorithm in some rendering code; fix pushed to master and -4-0. It is now ~instant to select for me. Having said that I'm troubled that that VCL window appears to have 6000+ children - though why I have no idea: #0 Window::GetChildCount (this=0xb280e80) at /ssd/opt/libreoffice/master/vcl/source/window/window.cxx:7988 ... Value returned is $4 = 6968 slowness occurring like this: Thread 1 (Thread 0xb49b7980 (LWP 20933)): #0 Window::GetChildCount (this=0xb280e80) at /ssd/opt/libreoffice/master/vcl/source/window/window.cxx:7988 #1 0xaf36eb78 in sdr::overlay::OverlayManagerBuffered::ImpBufferTimerHandler (this=0xbc1baa8) at /ssd/opt/libreoffice/master/svx/source/sdr/overlay/overlaymanagerbuffered.cxx:358 #2 0xb6bc1c4c in Call (pCaller=0xbc1bd1c, this=0xbc1bd2c) at /ssd/opt/libreoffice/master/solver/unxlngi6.pro/inc/tools/link.hxx:123 #3 Timer::Timeout (this=0xbc1bd1c) at /ssd/opt/libreoffice/master/vcl/source/app/timer.cxx:245 #4 0xb6bc1cfb in Timer::ImplTimerCallbackProc () at /ssd/opt/libreoffice/master/vcl/source/app/timer.cxx:133 #5 0xb40f49b2 in CallCallback (this=<optimized out>) at /ssd/opt/libreoffice/master/vcl/inc/saltimer.hxx:57 #6 sal_gtk_timeout_dispatch (pSource=pSource@entry=0xbc23fc8) at /ssd/opt/libreoffice/master/vcl/unx/gtk/app/gtkdata.cxx:844 #7 0xb60b47d3 in g_main_dispatch (context=0x8082e38) at gmain.c:2539 #8 g_main_context_dispatch (context=context@entry=0x8082e38) at gmain.c:3075
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c98ad71478cb72b51634b32d6e553ccaec30190 fdo#58029 - substantially accelerate re-rendering of complex forms 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.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b69b6eff232ac7e4897a28cc3422aa61171f4329&g=libreoffice-4-0 fdo#58029 - substantially accelerate re-rendering of complex forms It will be available in LibreOffice 4.0. 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.
Seems to be working fine. Thanks for your help!
FWIW, as you've seen the GetChildCount and GetChild(position) are epically slow and dumb. Can use e.g. for (Window* pChild = pWindow->GetWindow(WINDOW_FIRSTCHILD); pChild; pChild = pChild->GetWindow(WINDOW_NEXT)) { ... } to visit each immediate child of pWindow, and a call to pWindow->GetWindow(WINDOW_FIRSTCHILD) to see if there are any children. This isn't the first time there's been loads of children of a writer window. The last time I think they were from the header/footer/page separator decorations or some such
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=38dcfadda85058a0ee87292c8943aec82e34b81e fdo#58029: replace quadratic child window loop with linear 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.
the fix in comment #12 introduced bug 60444 so i've reverted it and did a different fix following the suggestion in comment #15, which should also scale linear in number of child windows.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=576cc750e38108ada5ea40870f1fe8cf2054e7b6&h=libreoffice-4-1 fdo#58029: replace quadratic child window loop with linear It will be available in LibreOffice 4.1. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=904de3293692949eba25229b27a6e1afaabc183b&h=libreoffice-4-0 fdo#58029: replace quadratic child window loop with linear It will be available in LibreOffice 4.0.5. 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.
Migrating Whiteboard tags to Keywords: (perf) [NinjaEdit]