Summary: | Large Writer document 15x slower to open in 7.3.7.2 and does not open at last cursor position | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | JohnHa <john.ha24> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEEDINFO --- | ||
Severity: | normal | CC: | dgp-mail, john.ha24, stephane.guillou, telesto |
Priority: | medium | Keywords: | bibisectRequest, perf, regression |
Version: | 7.3.7.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=141586 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 109530 | ||
Attachments: | Large file with 2,500 A4 pages of text |
Description
JohnHa
2022-11-18 02:25:26 UTC
Created attachment 183654 [details]
Large file with 2,500 A4 pages of text
Large file with 2,500 pages of A4 default text.
My User data was
Forename: John
Surname: Ha
Initials: JH
"the cursor is at the first character in the file and not at the last cursor position" is the direct consequence of the slowdown, and is bug 141586. On the other hand, it opens fast (under 4 s on my system) using Version: 7.4.3.1 (x64) / LibreOffice Community Build ID: 3793858a34d8fef5b92f8fee233f97766f05e281 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL => WORKSFORME? I can't reproduce. Open and responsive in about 10 seconds with: Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Open and responsive in about 7 seconds with: Version: 7.3.6.2 / LibreOffice Community Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Could be Windows-specific, but in any case, version 7.3 is not supposed to get further bugfix releases, so could you please try it with 7.4 ? (Snappy as well for me.) I (OP) cannot reproduce today. I was doing testing by saving with the cursor in various positions in the file and it was reproduceable so I am wondering if it is cursor position dependent and/or related to the cursor location problem bug 141586. When testing this morning on the first occasion it opened OK and I could scroll, but it then locked up. I had minimised its window and I could not re-open the window. CPU was at 26%. On the second, third and fourth tests it opened within a few seconds and did not lock up. My PC is minimal with few startup programs which could interfere. [Automated Action] NeedInfo-To-Unconfirmed I can't reproduce the slowness opening the document, but I can see some performance issues (high CPU use) with such a large document in all versions tested (7.0 to recent 7.5 master build). I found it hard to test, as one has to be sure not to trigger bug 147802 (fixed in 7.4.4 and master) when testing, as it can really hang Writer and delay actions like scrolling, selecting, saving and closing. Could you please test in a current master build, to make sure that the header/footer issue is not part of the problems you see: https://dev-builds.libreoffice.org/daily/master/current.html (In reply to Stéphane Guillou (stragu) from comment #7) > I found it hard to test, as one has to be sure not to trigger bug 147802 Note bug 152019 comment 1, describing how to disable that feature in any version, thus allowing to eliminate this aspect from testing. I don't experience any slowness. Re-opening at cursor position doesn't work out well, though. Sometimes it works I end up somewhere different (not on the first page though) My (OP) PC is 2 x 3GHz, 7 GB, SSD. Using the latest build as linked 1. File always opens quickly 2. If the cursor was in the middle of the file (page 1,521), after opening there is a pause of about 6 - 8 seconds before the file jumps to the saved cursor position on page 1,521. 3. If the cursor was towards the end of the file (page 2,497), after opening the page count remains at Page 1 of ..., and the screen view is at an unknown place. After 6 - 8 seconds the cursor jumps to page 2,476 - ie not the correct place. 4. If the cursor was at page 2,300 there is a pause after opening of about 17 seconds before the document jumps to the page 2,300 cursor position. This suggests to me the file in 3. was attempting to open at the cursor position but ran out of time. 5. After Save, there is a 15 to 20 second pause before the green bar starts crossing the screen. The file then saves quickly. The file is flat, unformatted text without headers, footers, footnotes, images, tables etc - just continuous default text. Continuing ... I disabled the "open at cursor position" option. 1. The file opened quickly at a position well towards the end of the file as suggested by the scroll bar on the window but the page count said Page 1 of ... (I didn't check the ...). After 8 - 10 seconds I moved the mouse and the page count changed to Page 2,265 and the cursor was in that page. 2. I repeated the test and did nothing. After 40 seconds the page count still said Page 1 of .... I brought the mouse into the window and the page count changed to Page 2,265 of 2,498 and the cursor appeared in page 2,265. [Automated Action] NeedInfo-To-Unconfirmed I can confirm the issues with LibreOffice Writer being slow in opening large .odt files and then not remembering the last cursor position if the cursor was last somewhere in the latter part of the document. Can reproduce with the Vanity Fair document from OP. Some of the issues with reproducibility might just have to do with hardware and the sizes of the files. I work with files that can be larger than the example here, and take longer to open. E.g., one ~1,500 page file I frequently work with (more complex formatting than the example here) takes 15 seconds to open on a recent ThinkPad T14 laptop with a new i5 processor, whereas it takes a full minute on an older ThinkPad T420s laptop (11 years old). The cursor issues happen in both though. I'm on version 7.4.4.2, but this has been happening for a while now. Tested on Kubuntu 22.10 (Plasma 5.25.5), X11; happens in regular Ubuntu versions as well. This is definitely not a Windows-only problem. John Ha, unfortunately nobody could confirm you bug so far. So I'd like to ask, if it is still valid, because. a new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? => NEEDINFO |