Bug 133856

Summary:	ODT file developed in .NET take 8-10 minutes to open in LO Writer as compared to Word just take few seconds
Product:	LibreOffice	Reporter:	Remus <remus.iftimie>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	NEW ---
Severity:	normal	CC:	buzea.bogdan, himajin100000, rb.henschel, serval2412, timur, xiscofauli
Priority:	medium	Keywords:	perf, wantBacktrace
Version:	4.1 all versions
Hardware:	All
OS:	All
Whiteboard:
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	103100, 136524
Attachments:	The ODT created in .NET with IndependentSoft ODF API Document opened with Word 365 and resaved in ODF format

Description Remus 2020-06-10 11:20:53 UTC

Description:
I am a .NET developer and I currently work on a reporting project that involves extracting data from M. Office files and convert them in a new ODF format as ODT and ODS using IndependentSoft ODF API. I've completed a test file from simple txt to ODT. The initial text file include a table formed of 55 columns and 4000-5000 rows. I'm extracting just some specific columns from there and do some processing background (concatenate some columns) and the final output is an ODT of no more than 700 kb.
The issue is when I open the file with LibreOffice it takes around 6 seconds to open but freezes(can't scroll) until fully loads the table (around 8-10 minutes). But when same file is open with M. Word or ODTViewer is only takes just a couple of seconds and is loading smoothly in background while I can scroll and is fully responsive
I found that the issue is on styling the document. As per data population there is no problem. So I thought there could be some style to override or some patch, dll to include on my project

Steps to Reproduce:
1. ODT developed in .NET and IndependentSoft API
2. Take 6 seconds to open but Not Respondint until fully loaded 8-10 minutes
3. Every time when I open with LO Writer is the same issue

Actual Results:
The opening time is huge

Expected Results:
Normal opening time (few seconds)

Reproducible: Always

User Profile Reset: No

Additional Info:
If I save a copy in M. Word still as ODT extension it triples in size but open in normal time in LO Writer

Comment 1 Remus 2020-06-10 11:27:44 UTC

Created attachment 161832 [details]
The ODT created in .NET with IndependentSoft ODF API

Comment 2 Julien Nabet 2020-06-10 12:57:19 UTC Comment hidden (obsolete)

Did you give a try to 6.4.4?
Indeed even if 6.3.6 is slow, 6.3 branch is EOL (see https://wiki.documentfoundation.org/ReleasePlan/6.3) so it won't be a 6.3.7 version.

Comment 3 Xisco Faulí 2020-08-11 11:06:09 UTC

I killed LibreOffice after

real	6m56,595s
user	6m53,482s
sys	0m2,790s


Version: 7.1.0.0.alpha0+
Build ID: 0de191e1d201d691c2196cf1aef412a98affb66f
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Comment 4 Xisco Faulí 2020-08-11 11:13:32 UTC Comment hidden (obsolete)

@Regina, if you have a moment, could you please doublecheck the document attached ?

Comment 5 Xisco Faulí 2020-08-11 11:14:26 UTC

Also reproducible in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

Comment 6 Regina Henschel 2020-08-11 12:54:54 UTC

Created attachment 164158 [details]
Document opened with Word 365 and resaved in ODF format

The validator shows three error.
1) root: The file 'mimetype' shall not be compressed in the ODF package 'LO 133856 newDOC.odt'!
2) manifest.xml: element "manifest:manifest" is missing "version" attribute
3) content.xml: element "office:document-content" is missing "version" attribute

Error 2) exists in the resaved document too and is ignored by LibreOffice.
Errors 1) and 3) are removed by Word.

The resaved file opens in LibreOffice.

The file has one table with 7 columns and 4470 rows ! That results in one table covering 338 pages.

There is indeed a problem with such large tables. First opening does not get the correct number of pages. Switching to Web view and back to Normal view brings the correct number.

Word opens it quickly, but that is misleading. It prepares the first page to show it to the user and you will see delay when scrolling through the document. I don't now for sure, but I think, LibreOffice first goes through all pages and then presents it to the user.

So there are three problems:
LibreOffice should be more tolerant with packing errors and version attribute errors.
We should re-think about the opening process, and consider showing preliminary results to the user.
LibreOffice needs better performance with large tables. Bug 132206, bug 126788 and bug 125171 might be related.

[I have not yet tried to open the original file, that will follow.]

Comment 7 Regina Henschel 2020-08-11 13:26:11 UTC

Opening lasts 13 min here, tested with Version: 7.0.0.2 (x64)
Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL

It has 317 pages.

Switching to Web view is quick but switching back to Normal view has performance problems too. Therefore I suspect the algorithm for calculating page breaks in tables.