Bug 58029 - EDITING: Selecting words in very large documents needs too much time
Summary: EDITING: Selecting words in very large documents needs too much time
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta1
Hardware: Other Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:4.1.0 target:4.0.0.0.beta0 tar...
Keywords: perf, regression
Depends on:
Blocks:
 
Reported: 2012-12-08 18:44 UTC by Rainer Bielefeld Retired
Modified: 2015-12-15 11:35 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 Rainer Bielefeld Retired 2012-12-08 18:44:46 UTC
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
Comment 1 David 2012-12-08 21:45:26 UTC
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.
Comment 2 David 2012-12-09 03:10:35 UTC
I did some more testing.  I think the delay in zooming and scrolling only occurs when text is selected
Comment 3 David 2012-12-09 13:06:01 UTC
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.
Comment 4 David 2012-12-09 18:31:31 UTC
Just a note in case it makes a difference.  I am running this on Ubuntu 12.10 64bit using KDE plasma.
Comment 5 Rainer Bielefeld Retired 2012-12-09 19:02:44 UTC
@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.
Comment 6 Rainer Bielefeld Retired 2012-12-09 20:10:27 UTC
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.
Comment 7 David 2012-12-09 20:40:28 UTC
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.
Comment 8 Rainer Bielefeld Retired 2012-12-09 21:27:24 UTC
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
Comment 9 Rainer Bielefeld Retired 2012-12-09 21:50:08 UTC
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,
Comment 10 Michael Meeks 2012-12-11 16:19:42 UTC
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.
Comment 11 Michael Meeks 2012-12-12 11:36:43 UTC
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
Comment 12 Not Assigned 2012-12-12 11:41:45 UTC
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.
Comment 13 Not Assigned 2012-12-12 13:58:53 UTC
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.
Comment 14 David 2012-12-13 15:38:59 UTC
Seems to be working fine.  Thanks for your help!
Comment 15 Caolán McNamara 2013-02-06 15:16:40 UTC
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
Comment 16 Commit Notification 2013-06-24 18:30:02 UTC
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.
Comment 17 Michael Stahl (allotropia) 2013-06-24 19:57:31 UTC
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.
Comment 18 Commit Notification 2013-06-25 17:20:21 UTC
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.
Comment 19 Commit Notification 2013-06-27 19:23:31 UTC
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.
Comment 20 Robinson Tryon (qubit) 2015-12-15 11:35:34 UTC
Migrating Whiteboard tags to Keywords: (perf)
[NinjaEdit]