Description: A large document (six copies of Vanity Fair, 2,500 A4 pages, 1.8 million words, just plain default text - no images, tables, footnotes etc) takes about 120 seconds to open in 7.3.7.2. It opened in about 8 seconds in 7.0.6.2. When it does finally open the cursor is at the first character in the file and not at the last cursor position. Steps to Reproduce: 1. Download attached Vanity Fair - six copies.odt. 2. Open with 7.3.7.2 and make an edit towards the end. This places your information as editor and should allow to document to open at the cursor position. 3. Note the cursor position. 4. Save file. 5. Open file. Actual Results: 1. It takes about 120 seconds before the blue circle stops spinning and I can type, scroll etc. 2. The file opens with the cursor at the beginning. Expected Results: 1. The file should open in about 8 seconds and allow me to type, scroll etc as it did in 7.0.6.2. 2. The file should open with the cursor at the position at which YOU last saved it as it did in 7.0.6.2. Reproducible: Always User Profile Reset: Yes Additional Info: 1. See also Bug 152097 - Writer document does not open at last cursor position where much smaller document opens with cursor at random positions. 2. This appears to be a regression - all worked OK with 7.0.6.2. 3. I had User Data in Tools > Options ..., which is necessary for LO to open the file at the last cursor position. 4. Resetting the profile (delete...\user, then add back User Data) had no effect.
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.
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.