Description: Save a txt file Open with LO writer as default Takes an inordinate amount of time to open, with many Not Responding messages Steps to Reproduce: 1.Save a txt file 2. Open with LO writer as default 3. Takes an inordinate amount of time to open, with many Not Responding messages Actual Results: Even in safe mode, Not responding Expected Results: Open a simple txt file as it did in prev versions Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no
Created attachment 196058 [details] actual file causing the crash I've tried rebooting, safe mode, same results
Using Text (encoded) filter, and making sure that LF is used as paragraph separator, makes it work OK. From the user PoV, this is Windows-only (on other OSes, LF will be used as paragraph separator automatically). This is a performance regression. In 24.2, it performed ~reasonably well with one huge paragraph separated by line breaks.
Regression introduced by: author Jonathan Clark <jonathan@libreoffice.org> 2024-04-29 04:30:43 -0600 committer Jonathan Clark <jonathan@libreoffice.org> 2024-05-17 17:35:41 +0200 commit 30d376fb7ded4c96c85ad1112a0e44b5929657c9 (patch) tree 453a767487aa4c09a5adc9adefcf932d0613d63f parent 5e88d86d8c41b6790a365fddadbcea76712c11f3 (diff) tdf#61444 Correct Writer text layout across formatting changes Bisected with: bibisect-win64-24.8
1. Does this also happen if we convert this document into an ODT with line-breaks-only? 2. That file is pure ASCII according to chardet (a python script) - so the problem isn't with RTL vs LTR runs. 3. If we don't have a perf-regression test which involves opening a long (text?) document with only line-breaks, we should probably add one.
This regression was fixed in master by the following commits: commit 4c8f88bef948b18f3d810c29a7f83496367758a9 Author: Jonathan Clark <jonathan@libreoffice.org> Date: Fri Jul 12 13:40:34 2024 -0600 tdf#92064 sw: Improve Tibetan layout performance commit 0e659fee706e5b7cd2c941d1513fbb162c3b38aa Author: Jonathan Clark <jonathan@libreoffice.org> Date: Tue Sep 3 05:49:28 2024 -0600 tdf#92064 sw: Improve large paragraph layout performance To validate the performance improvement, I conducted the following experiment using the attached text file: $ time ./instdir/program/soffice --headless --infilter="Text (encoded):UTF8,CRLF,,," --convert-to "pdf" ../runlogcreated.txt Results: libreoffice-24-2-6 (baseline) user 0m0.950s libreoffice-24-8-1 (regression) user 1m35.400s After cherry-picking commit 1 user 0m12.292s After cherry-picking commits 1 and 2 user 0m0.586s Based on these results, I am marking this bug fixed.
In a local build - With only 4c8f88bef948b18f3d810c29a7f83496367758a9 it takes: real 1m18,402s user 1m18,253s sys 0m0,196s - With only 0e659fee706e5b7cd2c941d1513fbb162c3b38aa ( 4c8f88bef948b18f3d810c29a7f83496367758a9 is reverted ) it takes: real 0m10,059s user 0m9,913s sys 0m0,208s - With both 4c8f88bef948b18f3d810c29a7f83496367758a9 and 0e659fee706e5b7cd2c941d1513fbb162c3b38aa it takes: real 0m10,005s user 0m9,854s sys 0m0,184s
I also don't get the not-responding behavior and opening the file is pretty snappy, so verifying. (In reply to Xisco Faulí from comment #6) I wonder if, when posting timings, it might make sense to subtract the time it takes to, say, create a new document, or maybe even open an empty text file, since some of the 10 seconds is LO's own startup, which masks perf differences. Of course there is the question of the variance in startup time :-(
Apologies if I am out of my depth here, but if this VERIFIED FIXED status was rolled into release 24.8.1.2 x86_64, it has not been fixed.... Thank you for all you guys do!!
(In reply to telrod11 from comment #8) > Apologies if I am out of my depth here, but if this VERIFIED FIXED status > was rolled into release 24.8.1.2 x86_64, it has not been fixed.... > > Thank you for all you guys do!! Thank you for the bug report. The fix is not in 24.8.1. It will be available in 24.8.2.
Again, apologies for overstepping, thank you for the clarification