Bug Hunting Session
Bug 63640 - FILEOPEN/FILESAVE: particular .odt loads/saves very slow
Summary: FILEOPEN/FILESAVE: particular .odt loads/saves very slow
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.3.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0
Keywords: haveBacktrace, perf
Depends on:
Blocks: File-Opening
  Show dependency treegraph
 
Reported: 2013-04-17 11:49 UTC by Mike Kaganski
Modified: 2019-06-03 17:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Empty file that loads/saves very slowly (105.45 KB, application/vnd.oasis.opendocument.text)
2013-04-17 11:49 UTC, Mike Kaganski
Details
Perf flamegraph (969.35 KB, image/svg+xml)
2019-04-19 07:45 UTC, Buovjaga
Details
The Complete Works of William Shakespeare (2.34 MB, application/vnd.oasis.opendocument.text)
2019-06-03 16:45 UTC, David García
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2013-04-17 11:49:34 UTC
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.
Comment 1 Jorendc 2013-04-17 20:45:20 UTC
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
Comment 2 Mike Kaganski 2013-04-18 00:10:25 UTC
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?
Comment 3 QA Administrators 2015-03-04 02:23:39 UTC Comment hidden (obsolete)
Comment 4 Mike Kaganski 2015-03-05 13:22:08 UTC
(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.
Comment 5 tommy27 2016-04-16 07:29:04 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2017-05-22 13:27:33 UTC Comment hidden (obsolete)
Comment 7 Mike Kaganski 2017-05-22 14:17:26 UTC
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
Comment 8 QA Administrators 2018-05-23 02:35:40 UTC Comment hidden (obsolete)
Comment 9 Roman Kuznetsov 2019-01-28 19:13:44 UTC
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
Comment 10 Buovjaga 2019-04-19 07:45:40 UTC
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
Comment 11 Commit Notification 2019-04-29 06:31:06 UTC
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.
Comment 12 Commit Notification 2019-04-29 06:32:40 UTC
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.
Comment 13 Commit Notification 2019-04-29 06:32:47 UTC
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.
Comment 14 Commit Notification 2019-05-07 08:55:04 UTC
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.
Comment 15 Xisco Faulí 2019-06-03 16:07:19 UTC
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!
Comment 16 David García 2019-06-03 16:45:56 UTC
Created attachment 151878 [details]
The Complete Works of William Shakespeare
Comment 17 David García 2019-06-03 16:46:33 UTC
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 18 David García 2019-06-03 16:49:11 UTC
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 19 David García 2019-06-03 16:50:51 UTC
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 20 Xisco Faulí 2019-06-03 16:52:35 UTC
(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
Comment 21 David García 2019-06-03 16:58:35 UTC
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.
Comment 22 Xisco Faulí 2019-06-03 17:06:43 UTC
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
Comment 23 David García 2019-06-03 17:13:05 UTC
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.
Comment 24 Xisco Faulí 2019-06-03 17:22:11 UTC
No problem, that is completely fine and thank you very much for your collaboration ;-)