Bug 61721 - FILEOPEN a large (19MB) XLSX file very slow
Summary: FILEOPEN a large (19MB) XLSX file very slow
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: target:4.1.0 target:4.0.2
Keywords: perf, regression
Depends on:
Blocks:
 
Reported: 2013-03-03 03:59 UTC by Wagner Macedo
Modified: 2015-12-15 11:36 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wagner Macedo 2013-03-03 03:59:00 UTC
Hello, today I tried to open this file http://www.ebscohost.com/uploads/ebooks/xls/eBookAcademicWW.xlsx, that has about 19 MB on LibreOffice Calc 4.0.0.3 and with about 7 minutes waiting, didn't open it. 

I didn't wait to see when (if) would open. I installed Gnumeric (1.10.17) to try and surprisingly opened in less than 20 seconds (I'm not saying that Gnumeric opened it perfectly, but I was able to read and search in the contents).

I'm using Kubuntu 12.04 with LibreOffice debian packages available in the site.
Comment 1 Alberto Ferreira 2013-03-03 10:08:56 UTC
Hello, 

I haved tried to open this file on LibreOffice Calc 4.0.0.3 in Windows and it take to long to open.
Comment 2 Jorendc 2013-03-03 19:30:08 UTC
I also can confirm this behavior using Mac OSX 10.8.2 with LibreOffice 4.0.1.2 rc2 and LibreOffice Version 4.1.0.0.alpha0+ (Build ID: 5fcb553c862d407aadb0320925723d3c2f70bfe)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2013-02-26_22:56:53.

But opening using Excel (for Mac) 2011 also result in this behavior ... So if even the program that creates this document can't open this document correctly, I'm not marking this yet as 'NEW'. I'll discuss this on the QA-mailing list.

Kind regards,
Joren
Comment 3 Jorendc 2013-03-03 22:53:32 UTC
Thanks to the response of a core developer I set the bug status to NEW, although the fact it have also performance issues using Excel.

@Wagner: thanks for reporting :-)!


-------------------
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage  There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-list
Comment 4 Wagner Macedo 2013-03-04 01:16:14 UTC
OK. Thank you for your good work.
Comment 5 Rainer Bielefeld Retired 2013-03-04 06:59:43 UTC
I saw this Bug mentioned on aq mailing list and decided to do some tests:
[Reproducible] with  "LibreOffice 3.6.5.2 " German UI/ German Locale [Build-ID: 5b93205] {pull date 2013-01-18} on German WIN7 Home Premium (64bit).
I fileopen fromLibO Start Center File dialog, After 1/2 minute progress bar reaches 50%, here more or less any progress stops with maximum% CPU load. I killed after 5 Minutes.

MS Excel Viewer and old Gnumeric both need less than 1/2 minute to open the document.

SoftMaker FreeOffice also opens document quickly, but is limited to 65000 rows, so that result can not be compared.

Already [Reproducible] with server installation of "LibreOffice 3.5.7.2  German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit), works a little better than 3.6, reaches progress bar 75%, then any progress seems to stop with maximum% CPU load 

LibO 3.3.3: Progress bar reaches 100% after 2 Minutes, another 15s for adapt row heights, ready. So we have a regression here. 

Please add Witeboard tag “bibisectrequest” if you think that a bibisect result can ease your work.
Please change  Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
Comment 6 ringe 2013-03-08 19:26:26 UTC
This seems like a duplicate of bug 30770.
Comment 7 Markus Mohrhard 2013-03-09 13:36:07 UTC
(In reply to comment #6)
> This seems like a duplicate of bug 30770.

No, not at all. Except for developers nobody should mark duplicates of performance bugs. Nearly always assumptions about performance problems are wrong. In this case here the problem is that we started to import row heights from OOXML and use the UNO API for it. This is such a horrible idea that it causes a freeze of the load process because we are doing way to much crazy stuff there.

The solution is to remove the UNO API from the row height import and use ScDocument directly.
Comment 8 Commit Notification 2013-03-09 14:38:05 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e1c281c6c1a2bd55d99e1af2023444c960cf02a3

use direct calls to set row height, fdo#61721



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2013-03-11 08:44:20 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=146352a3dcb65c99ec1b1b83f7be04231a32b21d&h=libreoffice-4-0

use direct calls to set row height, fdo#61721


It will be available in LibreOffice 4.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 10 Wagner Macedo 2013-03-11 21:26:56 UTC
Wow, so quickly! You, guys, are awesome. Thanks!
Comment 11 Robinson Tryon (qubit) 2015-12-15 11:36:10 UTC
Migrating Whiteboard tags to Keywords: (perf)
[NinjaEdit]