Wait time to open a large document, 1,900 pages, or to make any edits, takes a minimum of 2.5 minutes. Interesting that saving the document only takes a few seconds. Unusable with large documents again. I filed this same bug a year or two ago. Now, it is having the same problems as before, but this time every time any edit is made, it appears that the entire document is scanned before it is visually displayed. The consequences are obvious. Unless you are using a supercomputer, one must sit there and wait. My pPresent file size is 1,900 pages. Save yourself some time & use a file half that size. Opening the document initially takes at least 2.5 minutes. It takes more than 2.5m to open a New Window, a second copy of the first. Deleting three pages freezes all instances of Writer for 4.45 minutes. Updating index takes over three minutes. Completely unusable. For me to edit my present file, removing personal information, would take two working days. For this reason I won't give you a test document. Please use the one I sent previously, or, if you no longer have it, make a simple text document at least 1,000 pages long. Do that by making one page, then copying & pasting until you have 20 or more pages, then stop, copy all pages, & paste multiple times until you have the desired document size.
Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Created attachment 193354 [details] test file
My original comment about creating a file by copying & pasting is wrong. A simple text file of 1,900 pages is only ~100kb in size. The problem evidently is with larger file sizes, not number of pages. This agrees with what I found years ago when I had many images in the document. I removed all of them because the speed degradation made the document unusable. Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
In your sample file, takes a few seconds, less than ten to load, and about forty seconds to recalculate the page's number with: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded The document is plenty of direct format, for both paragraph and character, and with a large table across several pages at the end. Seems the main issue is about recalculate pages number. Disabling automatic spellcheck, helps to move through the document. Maybe there is some option for paragraphs or tables, making it difficult to establish the pages.
Have tested with the attached document. First test with the original document. Opening the document only some seconds, but ready with counting of all pages about 1 minute. Then I deleted all direct formatting (Ctrl + A → Ctrl + M) and saved the file with a new name. Same behavior. So direct formatting seems not to be the reason for this behavior, but counting the right number of all pages (1811 pages here). I would never put so much pages into one document. When creating a book I'm using a master document, which connects to all chapters of the book. So I could edit the chapters without any problem and have to wait a little bit when connecting all in the master document. Doing this here with the German Base Handbuch (over 700 pages) with a lot of screenshots without any problem. But: I dont work with Windows: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
The wait time for me to open the file was up to about 30-ish seconds, and when I scrolled down with the scroll bar all the way down, it took about 10 additional seconds of scrolling up and down by itself trying to get to the last page. Interestingly enough, the amount of page numbers fixed itself when it stopped scrolling by itself. However, after everything was loaded and been open for a while, I was able to save and edit the file with no problems or delay.
Tested with: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded and Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: ko-KR (en_US); UI: en-US Calc: CL threaded
On MacOS Sonoma 14.1.2, I was able to open the sample file in 5 seconds. I can edit, scroll through the pages of the document, delete any number of pages, and update the index instantaneously. Takes a few seconds to save and when opened, it takes around 20-40 seconds to recalculate the number of pages. I tested the file with the following two builds: Stable Build Version: 24.2.1.2 (AARCH64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Master/Daily Build Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: c4023d3ec604abfff38be2053e2989c7ec2ba8c1 CPU threads: 10; OS: macOS 14.1.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded