Description: When editing big files such as those we use (2,4MB) with tables, bookmarks and thousands of footnotes, the loading time can go up to 1 minute or more and saving time is very long 2-7 seconds (sometimes it takes longer). If the user wants to use automatic saving s/he should then negotiate between a short saving time and a usability issue. If I use 1minute I cannot type continuously any more because I have to wait every minute for the saving process to finish. Steps to Reproduce: 1.Open file attached 2.Change saving settings to 1 minute (or) hit the save button Actual Results: Long saving times Expected Results: Should save in the background allowing users to keep working. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en.UTF-8); UI: en-US Calc: threaded
Created attachment 195905 [details] Test file
Saving in background is bug 48416. I do confirm the slow loading and particularly the long wait until a responsive UI. A bit tricky as a report as we are not sure which of the document elements are causing this. Looking at a flamegraph, a lot of work is spent in bookmarks and tables indeed.
Created attachment 197295 [details] Perf flamegraph of file opening With OOO_EXIT_POST_STARTUP=1 Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7b91fc00a01e973937861a212750b12ffaaf9501 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 29 October 2024
I looked at the attachment. It is configured for Web View, probably to circumvent performance issues. When I try to restore Normal View, Writer no longer responds and I kill it after some "reasonable" delay. As a consequence I could not determine how many rows of the table span several pages. A similar case was mentioned on AskLO where a table row spanned tens of pages. I concluded that a cell is considered as an independent sub-document and Writer loads the whole cell contents in memory before computing page breaks. And this is aggravated by the number of columns in the row, putting considerable stress on system memory management. The document has two tables, but they extend over a considerable number of pages. This could be a contributing factor. I met a similar issue with a user question on AskLO. Once the "monster rows" were split to single paragraph contents, the problem was partially solved. Splitting the table in smaller ones and eliminating omni-present direct formatting did the rest. So, author should check if (s)he abuses the table feature. Writer tables are intended to host short TABULAR text, not full text flow. What is the pupose of the 4-column table? Simultaneous translation in foreign languages? In this case a table is the unavoidable solution but care should be taken to limit the amount of data and avoid as much as possible rows spanning several pages.