** Possibly Related To ** I believe this bug is related to bug 48011, but I am reporting for Windows and 3.5.2 where 48011 is Linux and 3.5.0/3.5.1. (Maybe should be all 3.5.x, all platforms???) 48011 is focused on text in tables where this bug is focused on non-table text. (Maybe it's any text???) 48011 is critical severity, so I have set this to the same. If I should post this against 48011, please let me know and I will. I wasn't sure if that was proper and didn't want to step on the other bug. ** System ** Win7 64-bit, Core i5-480M, 8GB RAM, LO 3.5.2 (release), Language Tool 1.7 installed (disabling doesn't make a difference), only English dictionaries installed. ** Problem Description ** Open 700+ page document in Writer 3.5.2. After 2-3 seconds, soffice.bin process goes to 25% CPU (i.e., 100% of 1 core) as reported by Windows Task Manager for about 2m 15s (timed it). During this CPU spike, Writer is useless because response to typing is so S-L-O-W. By slow typing, I mean rendering, "This is a test of typing in LibreOffice 3.5.2" took 10+ seconds longer than it took me to type it. I originally thought this was a file open problem, but further testing revealed this is not the case (more about that shortly). Writer 3.4.3 (running same version of Language Tool) opens the same document and is ready to go. No slow typing. ** Additional Observations ** The document is plain text. Basic margins and a header (page number). No images, tables, bullets, etc. Portrait orientation (so likely not bug 48235). ODT format. Opening a much smaller document in 3.5.2., I see a short 25% CPU spike for <5 seconds, so the initial spike time seems to be related to document size. 3.5.2 does not seem to be counting pages, etc. It has the right page count as soon as the document displays on screen and that count never changes. 3.5.2 does not seem to be spell-checking. I see red wavy underlines before the CPU spike. I can jump to the end of the document before the spike starts and see red wavy underlines there. Likewise, a fast set of page downs before the spike shows red wavy underlines. I also tested with 300+ page lorem ipsum, which throws red wavy underlines under every word, so it's really obvious it had identified misspelled words. CPU was still spiked at 25% (1 full core) long after. Further testing showed that 3.5.2's issue is not limited to file open. After the file open settled down to 0% CPU, typing new text spiked the CPU core (CPU = 25%) every time. Slow typing as described above. CPU stayed spiked until Writer finished catching up with typing. I have reverted to 3.4.3 (had the install still, rather than download 3.4.6) and can report 3.4.3 performance for comparison. 3.4.3 also spikes the CPU to 25% on file open (100% of 1 core) for a couple of minutes (didn't time precisely). But 3.4.3. doesn't have the slow typing issue--ever. I can type immediately and Writer 3.4.3 keeps up with no problems. After file open settles down, 3.4.3's max CPU while typing new text is 2% in multiple tests (vs. 3.5.2's 25%). 3.4.3 will occasionally exceed 25% CPU during the file open spike, suggesting it is using part of a second core. Typing while CPU is 25% after a file open jumps to 26% CPU and stays there until I stop typing. Occasionally doing nothing, CPU will go as high as 28%. 3.5.2 never went over 25% (never more than 1 core). Wild guess/theory: Is 3.5.x limited to a single core where 3.4.x was allowed to use more than one core? I tried 3.5.1 but reverted to 3.4.3 when it showed similar slow typing behavior. I didn't check CPU use, etc. on 3.5.1, but since behavior is the same and 48011 describes similar behavior in 3.5.0 and 3.5.1 on Linux, this may be the same issue. If you need a test document, let me know. I can't post my working document, but I can use http://www.lipsum.com/ to generate a 10k word lorem ipsum and paste it multiple times to create a comparable page-count document.
Checked with: LOdev 3.5.3rc1+ Build ID: 51648779-22e3d74-d554af7 Windows 7 Professional SP1 32/64 bit AMD Phenom II X2 3.1 GHz, 8 GB RAM Lorem ipsumed 745 pages of plain text in English with page number in footer, saved as ODT. Initial load spike at ~56%. No slowness at any time.
Downloaded and installed 3.5.3rc2. The typing speed issue appears to be resolved. I'm still seeing an extended CPU spike, but that seems to be attributable to Language Tool 1.7 now. I also noted that, during the spike with Language Tool, CPU can exceed 25%, which it didn't in 3.5.x before. Subsequent test in 3.5.3 release confirms this is resolved in 3.5.3. I did note a selection performance issue (slow selection using keyboard in large document) and will post in a separate bug report.
Might be related to problem Bug 47644#c17 with attachment 59616 [details] @Jamee Mikell: Of course we need a test document. Can you confirm fix for your problems with fix for Bug 48011?
(In reply to comment #3) > Might be related to problem Bug 47644#c17 > > with attachment 59616 [details] > > @Jamee Mikell: > Of course we need a test document. > Can you confirm fix for your problems with fix for Bug 48011? Note this is fixed in 3.5.3. See comment 2. https://bugs.freedesktop.org/show_bug.cgi?id=48932#c2 Thanks.
Created attachment 61925 [details] Sample document thousands of pages I now hijack this Bug for problems I observe with attached sample document I created from "Bug 47644 - FILEOPEN: Huge load time and CPU load with .doc file" attachment 59616 [details] saving that document with LibO 3.5.4 as .odt That can be edited quite normal with LibO 3.4.5 and also with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 3b32204-7f92fce-2ba0a9f)]" (2011-09-03). But Editing (scrolling, typing) is a pain with 3.5.4 RC1
I doubt that so many users have 1000 pages documents, so only "major" Already [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 5d1a991-4cb1bac-ca7e6f5-9125509-ce71330)]" (2011-11-09) Older Versions (2011-09-06, but not 2011-09-03) work fine for a while, but after 1-2 Minutes editing LibO will crash @Caolán: May be this is a similar area as "Bug 48011 - LibreOffice 3.5 is unusably slow with large documents"?
Can't be *exactly* the same anyway as the other one was specific to the Linux gtk version.
SwPageFrm::PaintBreak/SwFrameControlsManager::GetControl shows up a lot on some sampling of what's happening during the slow bits
yeah, SwPageFrm::PaintBreak disabled == fast, SwPageFrm::PaintBreak enabled == slow
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b63766b3dd453a82f59db505c736d861f662cc0f Resolves: fdo#48932 super slow typing and scrolling in large documents
caolanm->cedric: can you give the above patch a look over and see if my assumptions are right. e.g. that there is only one/zero FrameControl for a SwFrm* in any given class, and that there's no need for the pToTest->IsHeader( ) == bHeader test because we keep the header, footer and page ones in different containers anyway, and that a FrameControl is always associated with the same SwFrm*, all in all we can use a map here and look up a FramControl using a SwFrm* directly as the key in a map, which makes this example *fly* along during scrolling and typing into it
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4bc06051d1bf484a6f98186f0a2d168b3d98b9cc&g=libreoffice-3-5 Resolves: fdo#48932 super slow typing and scrolling in large documents It will be available in LibreOffice 3.5.5.
Created attachment 63227 [details] test-bug.doc (Word 97-2000-XP) Just for testing help. This test file is from #47644 and is the source from which the other odt test file was generated. The difference is the file format.
Here is my results using LO 3.5.5rc1 under Windows 2000. - i still see a 100% CPU activity after document loading (using both the attached test files) and i was unable to see it falling down. Editing the document is still very difficult in this situation. - i've seen many crashes during this testing session: 2 out of 3 with the ".doc" file and almost always with the ".odt". It happens in the first seconds after the documents has loaded and just appeared on the screen. With the odt some second after you try to interact with the document. Now i'm in a loop where i'm trying to open the odt file and LO try to recover, it succeeds, then crash. - the ".doc" test document loads much much faster than ".odt" (1 minute versus 6 minute). Looks like the ".odt" executes more than one iteration before opening file, as shown by the progress bar.
I have confirmed that this bug is still not fixed on version 3.6.0 RC1. To make the failure occur, open the test-bug345.odt file attached to this thread for editing, scroll up & down in the document for 5 or 10 seconds and then randomly select any text. I have a 3ghz quad core computer and the application freezes on me and is unresponsive for 3 minutes before I can once again do any editing. As soon as I try to select any text again it again becomes unresponsive for another 3 minutes. On Windows XP it will seem to be working for a while and then the program will totally crash. I am still unable to upgrade from 3.4.6 because of this regression.
Its important to not reopen bugs which are fixed if you have some remaining problem which appears similar.. Please open a new bug with your exact problem and details of how to reproduce. We fixed the slow drawing of the inter-page widgets under this id. So there's got to be an additional problem we need to identify.