load .XLSX attachment 108343 [details] from Bug 85399 in 4.4.x master (it will take a few seconds but that's not the point of the current report) then save it as .ODS and close file once is finished. then click on the it's thumbnail in the start center to reload it. LibO hangs while reopening that .ODS. tested using 4.4.0.0.alpha1+ Build ID: 6ba8b7f5eacac969e4781d63718083a05491b1bc TinderBox: Win-x86@42, Branch:master, Time: 2014-10-24_02:23:51 here's my configuration (it's a 5 years old laptop): O/S: Microsoft Windows 7 Professional 64-bit SP1 CPU: Intel Mobile Core 2 Duo @ 2.26GHz RAM: 4,00GB Dual-Channel DDR2 @ 399MHz (6-6-6-18) Motherboard: Inventec 1505 (CPU)
Reproduced hang. Win 7 64-bit Version: 4.4.0.0.alpha1+ Build ID: 0a82645c360158f9cc0fdabe2a52f1ff8f981bed TinderBox: Win-x86@39, Branch:master, Time: 2014-10-24_06:59:23
I tried to test it. But my LO 4.3.2.2 (Win 8.1) already hangs up if I try to save it an ods file and I have to quit LO.
Not really hang in master but 100% CPU, perhaps endless loop. 4.3.4.0.0+ seems not be able to save this document as OpenDocument. Tested under Ubuntu 14.04 x86-64 with my own builds. Version: 4.4.0.0.alpha1+ Build ID: 8c6d3cd45e2183a19f91e9a30c1fdc699de393f8 Version: 4.3.4.0.0+ Build ID: 9e8429b51eb7a1ef151ba40bb606910354dd5506 Best regards. JBF
Doesn't hang on 4.5, had to wait a bit. Tommy, can you retest? Win 7 64-bit Version: 4.5.0.0.alpha0+ Build ID: 8c7f6830e767897d3a0e88f75fc8d7ef7fca95dc TinderBox: Win-x86@42, Branch:master, Time: 2015-01-06_00:47:25
retested with 4.5.0.0 alpha (late december build) under a Win8.1 x64 brand new laptop (SSD drive) and the loading is very very slow... it takes more than 2 minutes to load that .ods I suppose that on older PC the waiting time could be even longer... I'm gonna retest later on with the latest daily build
no change... it still takes 2 minutes and 21 seconds to load with latest master build. 4.5.0.0.alpha0+ Build ID: 90d8f4fca566e46171b260ee3aadc655871c92ba TinderBox: Win-x86@42, Branch:master, Time: 2015-01-10_00:24:59 Locale: it_IT @Beluga I revert status to NEW and change summary from: FILESAVE/FILEOPEN: LibO hangs opening .ODS saved from .XLSX to: FILESAVE/FILEOPEN: very slow loading of .ODS saved from .XLSX
Created attachment 116860 [details] .ODS version of attachment 108343 [details] no performance improvement in LibO 5.1.0.0.alpha1+ Build ID: df7595a5f5871f8343e4ee3869ad153e3ae4a7f3 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-25_14:29:31 I attach the .ODS saved version of the original .XLSX attachment 108343 [details]
it takes 2 minutes and 40 seconds to load with LibO 5.3.0.0.alpha0+ Build ID: 4c70a1a6666a079872b8f1966bd398e924dc1d1a CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-09-22_06:54:24 Locale: it-IT (it_IT); Calc: group
** 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
Remove myself from CC: not interested anymore in issues with MS things. Best regards. JBF
Created attachment 137358 [details] Callgrind output from 6.0 Took a callgrind of opening the .ods. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: 7a2e7c32d38db02aaa5d78d5e8aaf86cabfde586 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on October 28th 2017
Slow already in 3.3 Arch Linux 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to QA Administrators from comment #13) > ** 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 Not certain this is the correct place to comment. I have simply picked a relevant bug report that has the latest comment. Slow loading; I have identified that if any Calc file is loaded "raw" it takes a long time to load. However, If Calc is opened and a new file created then minimised - leaving calc in the background then the subsequent opening of any calc file happens at an acceptable speed.
Created attachment 150865 [details] Perf flamegraph Did it from the XLSX -> ODS -> reopen, but now it only takes about 16 seconds. Still took a flamegraph of ODS opening just in case and might show it to a dev. 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
the attached .ODS file takes real 0m49,353s user 0m35,714s sys 0m0,684s 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 and real 0m52,557s user 0m51,286s sys 0m0,714s in Version: 6.0.0.0.alpha1+ Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded not much progress seen here...
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b4b8a50110474fd7221be6ab5e295197076ed427%5E%21 tdf#85482 FILEOPEN: very slow loading of .ODS 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.
Verified in Version: 6.3.0.0.alpha0+ Build ID: 3ab6d246cc44617af5ed416b5d49f2f35b61ceea 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 now it takes real 0m15,858s user 0m16,464s sys 0m0,526s @Noel Grandin, thanks for fixing this!!