Created attachment 117820 [details] This small file takes minutes to load! I upgraded LO from whatever came with Mint 17.2 XFCE 64 bit to LO-5.0. Now however loading or even saving a file takes minutes despite having 32GBs, SSDs, RAM disk, and an I7-4910 cpu running at top speed. The spreadsheet is very small. It loads much faster on an old I3 laptop running off an SSD with LO-4.x than it does with 5.0. However if I run it from a ram disk and start it with "sudo nice --10 libreoffice5.0 --calc PriceLogDellM6800.ods" the speed is much better. Is there perhaps a problem with the latest version of 5.0 on loading this spreadsheet? I've looked at the log at "~/.config/libreoffice/4/user/uno_packages/cache/log.txt" but nothing of interest is there. Just times the program was closed. Is there something in the spreadsheet LO-5 doesn't handle correctly or is this a user bug of some sort. If a user bug how do I figure out what is causing it to hang for so long?
A bibisect and a valgrind would be really awesome here. https://wiki.documentfoundation.org/QA/Bibisect/Linux https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_Valgrind_log I can confirm: Ubuntu 15.04 x64 LibreOffice 5.0.0.4 (broken) LibreOffice 4.4.5.2 (works) Regresion Marking as: New Minor - can slow down professional quality work but will not prevent it; High - regression, would be nice to figure it out. Although we only have one test case it may indicate larger issues.
Unconfirmed with v5.0.0.5 under mint 17.2 x64. Unconfirmed with v5.0.0.5 under ubuntu 15.04 x64. File loads in seconds (not minutes), just like in v4.4.5.2 and earlier.
Created attachment 117845 [details] valgrind log of opening libre with file, saving one change, and exiting I installed valgrind and then issued this command: sudo nice --10 libreoffice5.0 --calc --valgrind PriceLogDellM6800.ods >& /tmp/valgrind.log Once opened I changed one cell, issued a save, then exited. It's the first time I used valgrind and if I used it incorrectly please let me know how to use it correctly. Thanks.
I'm not exactly sure what we use for "have-valgrind" but I'm just adding "have-backtrace" to indicate that there is some guidance as to what's going on. @Ivor - thanks 1000x over for doing the valgrind. We'd love to see you join QA over at http://webchat.freenode.net/?channels=libreoffice-qa
It could be hard to prove, but I have a suspicion this may be a duplicate of e.g. bug 42742 or some related issue. The attached spreadsheet contains external images - e.g. the "RAM" sheet contains http://i.dell.com/images/global/configurator/general/collapse_notselected.gif and others. There are known issues with loading external images - especially if something causes the image to load slowly (e.g. DNS issues) or the remote site to silently not connect at all. I also don't see any significant change in speed from 4.4 onwards. With some slight variation, it loads in under 2 seconds each time. Unfortunately that means it still needs someone who can actually reproduce this to look at it further and prove or disprove the above.
Couldn't reproduce. Mint 17.2 Cinnamon/XFCE 64 bit with LO-5.1 dev.
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
I've spent a bit more time with this one and I'm throwing it back to UNCONFIRMED. Reason: I just tested 5.0, 5.2, and 3.3 and get basically the same behavior for each. I'm not sure what I confirmed before but I don't see anything taking minutes....everything takes about 5-10 seconds.
Comment on attachment 117845 [details] valgrind log of opening libre with file, saving one change, and exiting valgrind is the wrong tool. callgrind(which is part of the valgrind tool suite) is the only one that makes sense here.
Opens instantly. Please retest. Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 334599030e7b45153107a3075f9049a7463aac80 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 22nd 2016
I have noticed since LO 5.2 RC1 on, and also now with LO 5.2.0.4 (Build ID: 066b007f5ebcc236395c7d282ba488bca6720265) that Calc is extremely slow when loading, scrolling and/or navigating between sheet. The files I work with have an average of 400 kb so nothing to do with the filesize. In addition, in time System Activity shows a substantial increase in LO memory consumption, starting from around 300.000kb and ending with 2.000.000kb during an hour or so of work. And at max 2 files are opened. OpenGL is disabled. Machine detail: OpenSuse Leap 42.1 KDE Plasma 5.7.3 KDE Frameworks 5.24.0 QT 5.7.0 Kernel 4.1.27-27-default OS 64-bit processor 4xIntel Xeon 2.80GHz Memory 16 GB
Further to my previous post I am giving you memory information from System Activity (right click on soffice.bin, Detailed Memory Information). Here is the outcome of total: Totals Pixmap 19128 KB (Might be stored in the graphics card's memory) Private 688544 KB (= 144992 KB clean + 543552 KB dirty) Shared 59100 KB (= 59036 KB clean + 64 KB dirty) Rss 747644 KB (= Private + Shared) Pss 697905 KB (= Private + Shared/Number of Processes) Swap 0 KB Is the "dirty" info OK. Regards, B.
Bojan: please open your own report instead of posting to this unrelated one.
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-20170131
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20170301