Created attachment 78132 [details] Empty file that loads/saves very slowly The attached .odt is just an empty document (i.e. I have removed everything from it, including any user style). Though, it opens very slowly (I see 35+ sec delay with no status bar progress at opening), and if I save it I see 15+ sec pause before status bar progress begins moving. The document was heavily edited by me during last four months, and at some point (I cannot remember more details, even the LO version affected) this problem began. After a while, I tried to localize the place that causes it, and ended up with this empty document that still has the problem. On the other hand, when I copied all data from my original document to a newly created one, that new document doesn't have that problem, so I can continue my work (thus setting severity to minor). I suspect some internal metadata corruption that is not detected nor repaired by LO. Possibly this attached file could assist finding the cause of it, and maybe fixing some related bugs. Possibly related: Bug 61891. My system: Win7 Russian x64.
Thanks for reporting! Looks like a corrupt styles.xml file in the odt document. Opening this using a package manager shows that it's 3,0MB big. Push the odt document through an ODF validator (http://odf-validator.rhcloud.com/) also give errors on the styles.xml file. I even can't open the xml file using Gedit (text editor of Linux Mint). Deleting the styles.xml file solves the problem. How is that possible? I really don't know. I'm think I need to leave that for an expert on this topic. @Bug reporter: was this document always saved/opened with LibreOffice (or OpenOffice)? @Michael: I think this is interesting for you. Don't know how this is possible, or we can do anything about that... Any ideas/input/actions, or will this be a WONTFIX? Kind regards, Joren
LO only, though different versions (always latest at home, 3.6.x at work). By the way, v.3.6.3.2 is affected, too; thus setting the Version appropriately. The document is created from template that was created using OOO. It is possible that the template itself was created from a MS Word template long ago (5+ years). It is extensively used in my employer company, and very complex documents are created. The problem isn't present in other documents. Thus, I assume that the problem originates from LO (possibly from some crash), but this isn't very important. The problem is to automatically detect and fix this. If this doesn't qualify as a bug, then it could be considered as an enhancement request?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1.2 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
(In reply to QA Administrators from comment #3) Unfortunately, it is still present with Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: ru_RU under Win7x64. The delay is still there, and have not changed.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Reproducible with Version: 5.3.3.2 (x64) Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: ru-RU (ru_RU); Calc: group
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
repro in Version: 6.1.4.2 Build ID: 1:6.1.4-0ubuntu0.18.10.1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: ru-RU (ru_RU.UTF-8); Calc: group threaded file is empty but I see changed Default paragraph style with user defined GOST Type BU font
Created attachment 150873 [details] Perf flamegraph Not so slow anymore, but I took a perf graph from file opening. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 18 April 2019
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/24503d5ddfc0a83ac88aa23d03b69ed47f989e8e%5E%21 tdf#63640 FILEOPEN/FILESAVE: particular .odt loads/saves very slow, part1 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/560a0f2fbe452d25fe78d6756919c11ec67f630f%5E%21 tdf#63640 FILEOPEN/FILESAVE: particular .odt loads/saves very slow, part3 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b1e36f4d264f1d8d8df4558ba0c781ccb93a4244%5E%21 tdf#63640 FILEOPEN/FILESAVE: particular .odt loads/saves very slow, part4 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f1ed27eed68228edbab5eb63951a602263e4c3a7%5E%21 tdf#63640 FILEOPEN/FILESAVE: particular .odt loads/saves very slow, part2 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
it takes real 0m10,108s user 0m9,659s sys 0m0,653s to open in Version: 6.3.0.0.beta1+ Build ID: 219e128553645911685b6061f7c5ea359a4c551c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded while in Version: 6.2.5.0.0+ Build ID: 0d657498080aad86f4b97309fff9bf589c57dc2e CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded it takes real 0m41,429s user 0m41,023s sys 0m0,704s setting to VERIFIED @Noel, thanks for fixing this issue!
Created attachment 151878 [details] The Complete Works of William Shakespeare
Hello, These are the results on my computer (first generation Intel Core i7 with 8 GB of DDR 3 RAM running Windows 10 1903, 18362.145): - LO 6.2.4: 29s. - LO 6.3.0 beta 1: 11s. I noticed, however, that there was no progress bar on 6.3.0 beta 1 and I decided to investigate the issue. I was also curious to know if big files were loaded faster on LO 6.3.0 beta 1, and so I did some testing with a long document that I created by opening a text file in LO 6.2.4 and then saving it as an ODT document. These were my results on 6.2.4: - Time to open the file: 3m51s. - Time to save the file (after replacing a character): 3m03s. In 6.2.4, there was a progress bar, but I noticed two things: - When opening the document, LO showed the progress bar and then got stuck for a good while until the document was displayed. - When saving the document, it happened the other way round: LO got stuck for a while, and then it showed a progress bar. These were my results on 6.3.0 beta 1: - Time to open the file: 2m25s. - Time to save the file (after replacing a character): 2m10s. I reached two conclusions about 6.3.0 beta 1: - I confirmed that there was no progress bar neither when opening nor when saving the document. - I noticed that both operations were faster, but still not fast enough, though I have to admit that my computer is quite old and slow by modern standards. I hope this information is useful, and I’m willing to provide more information if necessary. Thank you!
Comment on attachment 151878 [details] The Complete Works of William Shakespeare This is a document that I provide to test if big files are loaded and saved fast enough on LO, as I'm having problems myself.
Comment on attachment 151878 [details] The Complete Works of William Shakespeare This is a document that I provide to test if big files are loaded and saved fast enough on LO as I'm having problems myself.
(In reply to David García from comment #19) > Comment on attachment 151878 [details] > The Complete Works of William Shakespeare > > This is a document that I provide to test if big files are loaded and saved > fast enough on LO as I'm having problems myself. Hello David, Would you mind reporting it in a new report ? Thanks in advance
Hello, I'm afraid I wanted to edit my description of the document and I ended up publishing the same thing again. I haven't used Bugzilla a lot and I can't find how to edit or delete a comment. As for your request, could you be more specific? As I said, I don't have a lot of experience here. I believe my comment had to do with the topic of discussion in the sense that it referred to the case of a file taking too long to open, though my document is indeed quite long and presents different problems from the one discussed here.
Hi David, we track each problem in different reports, meaning this report was used the track the problem with the file attached, which is fixed now. The file attached by you might be another problem, thus create a new report in https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&format=guided Thanks
Hello, Xisco, Sorry: I thought I was complementing the discussion on this thread, and that's why I decided to expand it to include my particular case. As a general rule, I thought it was preferred to search for threads containing a similar problem to yours, but I suppose that, in this case, we are talking about two files taking too long to load for different reasons, which deserve different bug reports. In any case, I'll open a new bug report: I hope I didn't cause much trouble. I'm trying to collaborate more with LO, but I need to learn little by little how Bugzilla works.
No problem, that is completely fine and thank you very much for your collaboration ;-)