Description: The desktop has 16 GB RAM, the operating system is OpenSuSe Leap 15.3. It is host to a VM which has 4 GB RAM; the guest is Windows 10. The notebook has 16 GB RAM, the operating system is Windows 10. On all three systems, LO 7.2 is installed. I have an ODT file of 1.8 MiB (716 pages). Editing the file on OpenSuSe is exceedingly slow: I hit a key, and it takes half a second until the character appears in the file. On both Windows installations - thus even in the virtual machine! - this problem does not exist. My technical understanding is insufficient to know whether 1) OpenSuSe is just so much worse in memory management than Windows, or else 2) the LO implementation for Linux is so much worse than the implementation for Windows. Needless to say, the present bug report is relevant only if #2 obtains. Steps to Reproduce: 1. Load a really large ODT file. 2. Start typing in it. Actual Results: Appearance of characters on the screen takes longer than my typing. Expected Results: There should be no delay between a keystroke and its display. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: If this is of any interest to developers, I would need instructions on how to demonstrate the bug.
@Christian Well there are plenty questions to ask A) Is this specific a specific large document.. B) What is Desktop Environment? KDE/XFCE? C) What the source of LibreOffice? LibreOffice.org using package manager Not an expert on Linux either.. Adding also someone with more expertise..
@Telesto: Thanks for coming back. A) The larger the file, the heavier the problem. With those everyday files of two pages, every installation of LO runs smoothly. On the other hand, I have only one file of this size, so I cannot tell whether the problem would be the same with _any_ file of this size. (I could upload it [once more], but first I would have to obliterate the text.) B) On this Linux, I have KDE Plasma Version 5.18.6. C) I don't remember. However, opening Help > About LibreOffice, it says: Dieses Produkt wurde von OpenSuse zur Verfügung gestellt. This looks very much like I did not download it from the LO website, but instead used the OpenSuse package manager to install it.
(In reply to Christian Lehmann from comment #2) > @Telesto: > Thanks for coming back. > > A) The larger the file, the heavier the problem. With those everyday files > of two pages, every installation of LO runs smoothly. On the other hand, I > have only one file of this size, so I cannot tell whether the problem would > be the same with _any_ file of this size. > (I could upload it [once more], but first I would have to obliterate the > text.) You can check this for anonymising: https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission It would be nice to test an example file. As documents can have many different features, the slowdown can be due to some very specific thing. Also, are you running a Wayland session on Linux? You can check from the terminal with env | grep -i wayland If the command does not print anything, you are running an X11 session.
I followed the website instructions to sanitize the file. However, the comments keep their original text. On the one hand, it would not be appropriate to delete them because they are part of the size problem of the file. On the other hand, the comments contain the _really_ private information, so I would prefer to obliterate them. However, it cannot be done manually as there are 150 of them. Any suggestions?
(In reply to Christian Lehmann from comment #4) > I followed the website instructions to sanitize the file. However, the > comments keep their original text. On the one hand, it would not be > appropriate to delete them because they are part of the size problem of the > file. On the other hand, the comments contain the _really_ private > information, so I would prefer to obliterate them. However, it cannot be > done manually as there are 150 of them. Any suggestions? Annoying: Replace All is disabled, if Comments is checked in Find & Replace dialog's other options. The only remaining way seems to be to unzip the file and figure out a way to mass-anonymise the comments directly in the content.xml file in a text editor and then zip it again. Document files are really zip files, just with a different extension.
I am afraid if I touch the content.xml, it will get broken. Would you want to do it for me? I would then upload the file as it is now.
(In reply to Christian Lehmann from comment #6) > I am afraid if I touch the content.xml, it will get broken. > Would you want to do it for me? I would then upload the file as it is now. Yes, you can email it to me directly.
Created attachment 179343 [details] Example file I can reproduce slowness with 7.3, but not really with master. Notes from sanitising the comments: After unzipping, I ran this to have a non-minified xml to work with: xmllint --format content.xml > pretty_xml_file.xml For the pretty xml file, I used my Kate editor to do this regular expression find & replace: Find: (<text:span text:style-name="T[0-9]+">)([^<]+?)(</text:span>) Replace: \1xxx xxx xxx\3 It was tricky to find a suitable regex and I kind of gave up and settled for good enough. The reason is that there could be these types of elements inside the text spans: <text:s/> To explain the regex a bit: - it uses three capture groups - the capture groups are referenced in the replace statement with \1 and \3 (skipping the middle group as it had the private content) - the middle group says that we want any characters as long as they are not < - the +? means that there can be any number of characters in a "non-greedy" way, so it will stop looking when it hits the next </text:span> After the mass replacing, there remained only a few comments that I manually replaced in LibreOffice itself.
I now tried the original file on LO 7.4.0.0.alpha. The latency of keystrokes is the same as with earlier Linux versions. The Example file created by Buogjaga may be faster to edit because it does not have 1.8 MB, but only 1.2 MB.
Ok, now I notice that the lag is experienced when typing (esp. hitting a key and holding) into a paragraph containing a field. I checked some versions and the behaviour *might* have changed, but it seems too inexact to bother with a bibisect. Christian: can you confirm this distinction, if you try in paragraphs without fields?
Yes, this observation is apparently on the right track.
However, it may still be instructive to look why the Windows version fairs so much better on this count.
Created attachment 179374 [details] Perf flamegraph I took a perf trace of pressing a letter in a paragraph with fields in the example document. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: ff2f433cdfda74dbf69a11342a98ccbfb5bc6a72 CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
@Buovjaga did you try on a gnome desktop too ? The graph is similar or not ?
(In reply to Arnaud Versini from comment #14) > @Buovjaga > > did you try on a gnome desktop too ? The graph is similar or not ? By gnome desktop, do you mean an actual gnome desktop session or gtk3 vcl plugin? I did not try either.
A brief update on the earlier observation: In order to avoid turning thumbs until my keystrokes appear on the screen, I now work on that document in the Windows 10 virtual machine mentioned before. Although it runs in a virtual machine, it is perceptibly faster than LO running on the Linux host. However, even on Windows, the large document is clumsy. Summarizing, there appear to be two issues here: - LO cannot satisfactorily manage large documents. (I had some unsuccessful discussion in a different bug report on redundant markup in LO Writer documents and the necessity to offer the user a purge function.) - LO is slower on OpenSuse Linux than it is on Windows.
Update for LO 7.4.2.3: 1) Answer to comment 1, question C: It was downloaded from the official LO site and installed instead of the previous version. 2) The big file now has 2.116 KB on disk and 1,838,811 characters. It is no longer manageable on Linux; typing is far too slow. It is better with Windows, but if you are a fast typer, it would still be too slow. 3) The problem with typing under Linux is not merely that characters do not appear on the screen as you are typing, but with considerable latency. There is an additional problem: If you type a sequence of a non-character key (like right arrow or the like) and a character key, then they are entered into the file in reverse order. It is always the non-character which is delayed.