Large text files are now taking an extremely long time until the program responds to input. A sample 20MB text file can be downloaded from https://examplefile.com/text/txt/20-mb-txt. With LibreOffice 3.3, this file takes about 5-6 secs. until the file is loaded and the application is usable. With version 6.4.7, it takes about 30-35 secs. until the application is responsive. With version 7 through version 25.2, LibreOffice loads it fairly quickly but then is very sluggish for about 4-5 mins. until the file is fully processed and responds normally. With version 25.8 beta, the first page is displayed after a normal load time but then it takes over 1.5 hours on the same computer until any input will be accepted. This is not been tested on Windows.
Seems the issue is with the URL example.com, as if LO was trying to create the hyperlinks. When changing example.com to example-com, the problem does not occur. Version: 25.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 2e23aa4dbb7512c79e8a6547b80b27c6eb943d37 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded
Created attachment 201577 [details] sample text file This is not a problem specific to this file. It pertains to any large text file. This was simply a generic one that I found for testing. I guess I was under the assumption that anybody testing this would use the download button to download the file to their computer and then load it. The file has now been attached to this bug report.
Confirm Unable to edit the file with (also quite some memory usage 1,1 GB) Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6faa7e6f7bae3e6a613b4f4b7cee4a9c6d2b7aae CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded Opens quite fast, able to make edits. A idle job is running in the background (even when the word counter is finished) (SwFrame::ImplFindTabFrame) (also quite some memory usage 1,1 GB) Version: 6.4.0.0.alpha1+ (x64) Build ID: 9bc848cf0d301aa57eabcffa101a1cf87bad6470 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL Opening freezes with Version: 6.1.6.3 Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: nl-NL (nl_NL); Calc: CL same idle job as in 6.4 memory usage is lower: 600 MB or so, but well x32 build: Version: 5.2.5.0.0+ Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8 CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55 Locale: nl-NL (nl_NL); Calc: CL older version: hard to check; timers are operating different. Much more idle background tasks. Takes forever to finish. The most recent issue surely bibisectable. Other stuff is more food for a CPU profiler, IMHO --- Side-note, Writer isn't designed for opening huge txt files covering > 2000 pages. A text editor seems better equipped for handle this kind of files However the performance issue in recent versions is surely a regression.
(In reply to Telesto from comment #3) > Side-note, Writer isn't designed for opening huge txt files covering > 2000 > pages. A text editor seems better equipped for handle this kind of files > > However the performance issue in recent versions is surely a regression. Yes, it may not be typical for a word processor to be used as a text editor but then a text editor also isn't as capable for certain things. Though there was a slowdown that happened from version 7 through 25.2 until the file was fully processed, it has been a bit more manageable. The regression in 25.8 beta is rather extreme.
The time it takes for a file to be displayed as Filename (Active) in the Navigator tab in the sidebar after opening it Before the commit below, it was around 40 seconds, but now it's over 4 minutes. author Mike Kaganski commit b6bcc7ac278e0db22df02707789730ec123bf934 tdf#166871: drop mnMaxParaPerPage hack *** adding to CC:Mike Kaganski Please, take a look?