Created attachment 126468 [details] Excel xls file with many images (truncated file for testing) I am setting this up as a new bug report because it is a bit different from Bug 100442. I am running LO Calc Version: 5.1.4.2, and MS Excel 2007 (12.0.6750.5000) on a customized MSI Gaming Laptop with the following specs: Processor: Intel Core i-2760QM CPU @ 2.40GHz RAM: 16GB OS: Win7 64-bit [NOTE: I have NOT tested this on my Linux edition of LO Calc.] I originally became involved while answering a post on ask.libreoffice.com (see https://ask.libreoffice.org/en/question/74060/unable-to-open-xls-file-in-lo-calc/?answer=74199#post-id-74199). The xls file supplied by the OP had many images and 3,033 rows. File size was 34.5MB. Excel 2007 could open the file but LO Calc would crash after trying. After some tests and exchanges with the OP, I truncated the file to 651 rows for your testing. File size is 7.32MB. At 2,000+ rows, file open is quite slow but succeeds. As you approach 2,500 rows, file open fails.
Unconfirmed with v5.1.5.1 under windows 7 x64. Unconfirmed with v5.2.0.3 under ubuntu 16.04 x64. Opens reasonably fast over here.
No issue, Win10x64 Version: 5.1.5.2 (x64) Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5 CPU Threads: 1; OS Version: Windows 6.19; UI Render: default; Locale: es-ES (es_ES); Calc: CL Please test the memory set in Menu/Tools/LibreOffice/View - Memory cache, it's not less than 48 Mb, default value 64 Mb.
Yep opens quickly. Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists even after checking the setting asked in comment 2. Change to RESOLVED WORKSFORME, if the problem went away. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: f3d26af51588af441f62fb69bb7a5432845226ac CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on August 5th 2016
(In reply to m.a.riosv from comment #2) > No issue, Win10x64 > Version: 5.1.5.2 (x64) > Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5 > CPU Threads: 1; OS Version: Windows 6.19; UI Render: default; > Locale: es-ES (es_ES); Calc: CL > > Please test the memory set in Menu/Tools/LibreOffice/View - Memory cache, > it's not less than 48 Mb, default value 64 Mb. Memory is set at defaults as follows: Graphics Cache - Use for LO 128MB Memory per object 20MB Remove from memory after 10min Cache for inserted objects - Number of objects 20
Please test changing the use of OpenGL: Menu/Tools/Options/LibreOffice/View and disabling OpenCL if it is enable: Menu/Tools/Options/LibreOffice/OpenCL
(In reply to m.a.riosv from comment #5) > Please test changing the use of OpenGL: > Menu/Tools/Options/LibreOffice/View > and disabling OpenCL if it is enable: > Menu/Tools/Options/LibreOffice/OpenCL Disabled "Allow use of OpenCL." No effect. Further disabled use of software interpreter. No effect. Would it help if you had the complete file made available by the OP who posted the ask.libreoffice.org question? If so, the OP provided a link to the file at: http://rkb1c.ru/soft/35mb.xls
I can open the test file in 30 seconds under Win8.1 x64 using LibO 5.1.5.2 on an SSD drive.
No crash for me, and I checked with 5.1.4.2, 5.2.3.3, 5.3 daily build / Windows 7. Can you check again with 5.2.3.3? The large file opened in ages, but it opened in the end (I made some performance improvement to bug 100442 that should reduce loading times in 5.3, not saying it's going to be quick, but it should be much better).
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20170531
I have provided all the information I can, particularly since I was reporting a problem actually experienced by someone else on the ask.libreoffice.org forum. The forum post link is included at the beginning of this thread. I'd like to offer some constructive feedback concerning this thread. I also want to emphasize that this is CONSTRUCTIVE feedback -- no insult intended to anyone here who has tried to help. One thing I noticed in this thread is that several who responded failed to read or understand my original post. In the original post, I included a truncated file that WOULD open, indicating that the original file was much larger and also indicating the point of failure. There was no question, then, that the uploaded file (651 rows and 7.32MB) would open -- that was a given. The question concerned problems experienced when trying to open the original file (3,033 rows and 34.5MB). I even provided the exact point of failure (2,500 rows), but all of that seemed to go unnoticed by some responders. There were two reasons I provided the truncated file. First, I had a problem uploading the significantly larger file. Second, the truncated file provided sufficient material for testers to re-create the 3,033 row file. Since my last response, I had to delete the spreadsheet files I was holding; I had to release storage space (drive getting too full). As a result, I am no longer able to provide further information. I am therefore changing the status to UNCONFIRMED, and suggest an Administrator change the status to CLOSED. My thanks to all who responded. If you have further questions, perhaps you could contact the ask.libreoffice.org forum OP at the link I included in my original post.
Ok, Keith, I can explain. If you had provided steps to work on your truncated file, we would not have made the mistake. If you provide a file without steps, testers just immediately assume that "this is a problematic file" and go after it like a pack of rabid dogs. The active testers go through a massive amount of bug reports, so there is bound to be these sorts of mistakes, when a report is not clear (see this for some stats: https://blog.documentfoundation.org/blog/2017/05/31/libreoffice-quality-assurance-six-months-statistics-part-1/ ) The best approach would have been to just go with http://rkb1c.ru/soft/35mb.xls as the main attraction and not attach the truncated file at all. For the record, I can open 35mb.xls just fine. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.3.2 Build ID: 5.3.3-1 CPU Threads: 8; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; Locale: fi-FI (fi_FI.UTF-8); Calc: group
I downloaded http://rkb1c.ru/soft/35mb.xls and it open within a minute in Versión: 5.3.3.2 Id. de compilación: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 Subproc. CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: es-ES (es_ES); Calc: group However, it takes much longer in Version: 5.5.0.0.alpha0+ Build ID: 36b1e6270bf2fbb333e2a69c4bb5931eba418289 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-29_14:06:19 Locale: es-ES (es_ES); Calc: group Could someone please confirm it?
(In reply to Buovjaga from comment #11) > Ok, Keith, I can explain. If you had provided steps to work on your > truncated file, we would not have made the mistake. If you provide a file > without steps, testers just immediately assume that "this is a problematic > file" and go after it like a pack of rabid dogs. > > The active testers go through a massive amount of bug reports, so there is > bound to be these sorts of mistakes, when a report is not clear (see this > for some stats: > https://blog.documentfoundation.org/blog/2017/05/31/libreoffice-quality- > assurance-six-months-statistics-part-1/ ) > > The best approach would have been to just go with > http://rkb1c.ru/soft/35mb.xls as the main attraction and not attach the > truncated file at all. > > For the record, I can open 35mb.xls just fine. > > Arch Linux 64-bit, KDE Plasma 5 > Version: 5.3.3.2 > Build ID: 5.3.3-1 > CPU Threads: 8; OS Version: Linux 4.10; UI Render: default; VCL: kde4; > Layout Engine: new; > Locale: fi-FI (fi_FI.UTF-8); Calc: group Thanks, Buovjaga. I thought my original post was clear, but then I'm not a regular on bugzilla either. I'll keep your advice in mind for the future. Have a great day, --Keith L. Keith Jordan
(In reply to Xisco Faulí from comment #12) > However, it takes much longer in > > Version: 5.5.0.0.alpha0+ > Build ID: 36b1e6270bf2fbb333e2a69c4bb5931eba418289 > CPU threads: 1; OS: Windows 6.1; UI render: default; > TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-29_14:06:19 > Locale: es-ES (es_ES); Calc: group > > Could someone please confirm it? export OOO_EXIT_POST_STARTUP=1 time libodev libobugs/35mb.xls real 1m7,897s user 1m6,886s sys 0m0,912s Arch Linux 64-bit, KDE Plasma 5 Version: 5.5.0.0.alpha0+ Build ID: 963137415bcdf3e7a26ce5d258302f4e39e294db CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on May 31st 2017 I will next try a callgrind so Áron can look at it.
I think the importing time is quite acceptable taking into account the size of the document. However, visualizing and working with the document seems more fluent in 5.3.3 than in 5.5.0
Created attachment 133752 [details] Callgrind output from 5.5, opening 35mb.xls
(In reply to Xisco Faulí from comment #15) > I think the importing time is quite acceptable taking into account the size > of the document. However, visualizing and working with the document seems > more fluent in 5.3.3 than in 5.5.0 By my experience, dev builds are always slower than release builds. I guess they have controls that are not on published versions. About 10 seconds to open on: Version: 5.3.3.2 (x64) Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: es-ES (es_ES); Calc: group
(In reply to m.a.riosv from comment #17) > (In reply to Xisco Faulí from comment #15) > > I think the importing time is quite acceptable taking into account the size > > of the document. However, visualizing and working with the document seems > > more fluent in 5.3.3 than in 5.5.0 > > By my experience, dev builds are always slower than release builds. I guess > they have controls that are not on published versions. This is true for builds that have debug or dbgutil enabled, but Xisco's build did not: http://dev-builds.libreoffice.org/daily/master/Win-x86@62-TDF/current/master~2017-05-29_14.06.19_build_info.txt
I've just retested in Version: 6.0.0.0.alpha1+ Build ID: a7f961ddd88df4117de5f7c199881cf75d2905b5 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and it takes real 2m16,043s user 2m14,216s sys 0m1,176s to displayed the document ( using OOO_EXIT_POST_STARTUP=1 only takes 20 seconds )
tested with Version: 6.0.0.0.alpha1+ Build ID: 0b4d0c87fe201b7cc7f49b2dc14c134c95558a30 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-11-11_02:45:18 Locale: nl-BE (en_US.UTF-8); Calc: group it takes 7 seconds to open the attachment
Xavier: you need to open http://rkb1c.ru/soft/35mb.xls and not the attachment. I tried it again and it still takes the same amount of time as in comment 14
Now with the right file it takes 83seconds
100442
I can confirm with 32bit LO, win7-64bit. No crash (no patience from me to wait ), but I killed soffice after 10 minutes. Excel can open this file immediately. Setting as new. Version: 6.0.0.0.alpha1+ (from bibisect-win32-6.0 repo) Build ID: 80af51be1aa85733b9c0b696a93edd8c6520811c CPU threads: 4; OS: Windows 6.1; UI render: default;
** 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
With master build the hole system memory was in 2 seconds used, also a lot of swap memory was used and i did need to shutdown the pc I used the attachment 35mb.xls for the test Version: 6.3.0.0.alpha0+ Build ID: 82cc30a832dde298832d9f029e0ead94a9d2d14b CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded
It took over 2,8Gb of used memory while opening of example xls file. I tried in Version: 6.3.0.0.alpha0+ (x64) Build ID: 5a907fe76bc628629fddb5501727642468d38dae CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-22_00:18:04 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
it seems http://rkb1c.ru/soft/35mb.xls it much slower now. it takes real 6m18,398s user 0m10,091s sys 0m56,088s in Version: 6.3.0.0.alpha0+ Build ID: b34786d2774b261be48de92f65a5d0aa3c32b289 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 with OOO_EXIT_POST_STARTUP=1
Similar problem with Version: 6.1.0.0.alpha1+ Build ID: 3a801799536e6870f2fb111b1cc00b9575a35a39 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group ( oldest commit in bibisect-linux64-6.2 )
Regression mentioned in comment 28 and comment 29 reported in bug 124901
after https://git.libreoffice.org/core/+/af84fc9d906626255aaf136eefc5e55236e0e8a6%5E%21 it takes real 0m24,458s user 0m21,872s sys 0m0,969s in Version: 6.3.0.0.alpha0+ Build ID: 90e3b47b52f26420425a7417d2f51b6a386282d9 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 so the fileopen performance issue is fixed, however, it's still lagging while scrolling...
(In reply to Xisco Faulí from comment #31) > after > https://git.libreoffice.org/core/+/ > af84fc9d906626255aaf136eefc5e55236e0e8a6%5E%21 it takes > > real 0m24,458s > user 0m21,872s > sys 0m0,969s > > in > > Version: 6.3.0.0.alpha0+ > Build ID: 90e3b47b52f26420425a7417d2f51b6a386282d9 > 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 > > so the fileopen performance issue is fixed, however, it's still lagging > while scrolling... Since this issue has many comments and the slow import is fixed, let's close this one as RESOLVED WORKSFORME ( Improved by different commits ). Bug 124963 has been reported to cover the slow scrolling issue...