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.
Hello, I haved tried to open this file on LibreOffice Calc 4.0.0.3 in Windows and it take to long to open.
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
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
OK. Thank you for your good work.
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).
This seems like a duplicate of bug 30770.
(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.
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.
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.
Wow, so quickly! You, guys, are awesome. Thanks!
Migrating Whiteboard tags to Keywords: (perf) [NinjaEdit]