Same Spreadsheet with a lot of cells, that are bundled to other cells in some more sheets in the same file. To copy one cell and paste it to 5 other cells lasts in 4.4.3.2 only Milliseconds. Since I test 4.4.4.3 for an other bug, the Spinningwheel of Mac OSX is after every operation in front and I have to wait a few seconds… Oh no… - have been gone back to 4432. The same now in 4432… I just change one date in a cell and wait 10 seconds until it is finished… Will make a restart. Maybe it is an other problem…
are you still reproducing this issue after restart? have you tried resetting the user profile? https://wiki.documentfoundation.org/UserProfile
Hey Tommy, after I recognized that it is the same with 4.4.3.2 I installed 4.4.3.2 new with german language-pack. Same result: Spinning wheel 10 or more seconds to write a date in a cell. I renamed the "user"-folder… the same… I renewed the "caused formatting"(?) in all the sheets. The same. The cells which need the most time are cells formatted as date, with a "Validity"-check. (Don’t know in english…) There are to cells in a sheet called "preferences", which have a date for minimum and maximum for the Validity-check. Because it is not possible to make a Validity-check that points to a different sheet, every sheet include 2 columns with the Date-A (Minimum) and Date-B (Maximum) in every row. It works fine until I installed Version 4.4.4.3 Now, after I opened the last-year table, it goes faster in the actual table. After closing Libre Office, it need one time 5 seconds, but the 2. date I write in appears nearly immediately. A few tests later it need for the same operation 50 Seconds… I don’t know why and don’t know what happens here... Maybe there was something destroyed, when I duplicate the last years table, emptied it and copy-pasted the untouched rows from the button to the top, to have all formulas, caused formatting and "Validity"-check inside there.
@Manfred: Without the file causing the problem, or detailed steps telling us how to reproduce it, it is unlikely that we'll be able to process this bug report further. Setting to NEEDINFO.
Hi Alex, I send you the Spreadsheet as a personal message. Please do not upload it. Just open it and change any date in sheet "Kasse" in column "C" after line 30. Format has to be german: 15.7. (There is a "validity" inside.) After installing 4.4.4.3 it need lots of seconds at the first time I change the date. The next go faster. But if I change to a different file and go back to this one, the first entry lasts very long again. But as I wrote, maybe I destroyed something by emptying the last years sheet? Could this be a problem with any cache? Greetings from Germany Manfred
(In reply to Manfred from comment #4) Hi Manfred, Thanks will take a look, but I will not upload your sheet to the bug as you request. Bug 89986 might be of interest to you as well, as I have had severe performance issues there too.
On LO master 5.1 alpha, trying to change the date to say 21.07.2015 and pressing enter in cell C32 causes LO to enter an infinte lopp / hang / beachball spinning mode. Confirming
(In reply to Alex Thurgood from comment #6) > On LO master 5.1 alpha, trying to change the date to say 21.07.2015 and > pressing enter in cell C32 causes LO to enter an infinte lopp / hang / > beachball spinning mode. > > Confirming Actually, it took more than 3 minutes to complete the update. Undoing the update with Cmd-Z does the same thing - occupies the processor for at least 3 minutes, in fact far more than 3 minutes, more like 5 !! Context switching seems to help speed up (marginally) the process. Performance is just as bad for me with ersion: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale : fr_
On LO 4142, the file Manfred sent me takes 10 minutes to load ! At least the update only took a few seconds to execute. This performance problem seems to stem from the multiple recalculations that seem to be carried out when the date is changed. In this regard, it is similar to bug 66507
(In reply to Alex Thurgood from comment #8) > On LO 4142, the file Manfred sent me takes 10 minutes to load ! > > At least the update only took a few seconds to execute. > > This performance problem seems to stem from the multiple recalculations that > seem to be carried out when the date is changed. In this regard, it is > similar to bug 66507 Bug 66507 looks different. To change a sheet in my table is very fast. But one is similar: To switch to napokra-sheet need 15 seconds the first time. After going to an other sheet and switch back to napokra it is only 1 second. After autosave this change is 15 seconds again! This bug here occurred the first time, after I duplicated a table and opened it with version 4443. Before, the Original file in Version 4432, did not show this bug. Changing a date in a cell (formatted as date), and that is covered by a validity-check, last many seconds. Next date-entries go faster, but after Autosave, the first entry is slow again. To change a date without validity-check is very fast. To change a date with validity-check is slow !! I retest with 5.0.1, 64 bit: The same. Hardware: iMac 27-inch 3,5 GHz Intel Core i7 Load table: 12 seconds 1. Change the date in sheet "Kasse" in cell C32: 58 seconds 2. Change the date in sheet "Kasse" in cell C33: 3 seconds 3. Change the date in sheet "Kasse" in cell C34 (after autosave): 56 seconds Save and close (and autosave) is 7 seconds.
Is anybody working on that bug? It means a lot for me! Every day, nearly every cell I try to fill with data, I have to wait a lot of seconds and minutes more than necessary, until the Mac-please_wait-Spinball let me work further…!!! If this will not be fixed soon, I have to try an other application. But I came from AOO to LO in fact of a not fixed bug there with password protected files. Where shall I go, if this bug lasts? Excel?
The same behavior in 5.0.3.2 --- as every year James… ?????? Is anybody supporting bugs, discovered in Versions for Mac OSX above 10.6 ??????? (LO 4.3 and so on)… Does anybody in the Quantity of developers has such a machine? I think not… ! There are bugs, you, yes you! will act if you recognize them. Bugs like I reported. This app is nearly unusual for me if there is no support and the main bugs I reported are out there a few month later, like no one is interested to help with better code. See my other reported bugs. All that happened is something like: This is duplicate from that, this is not duplicate from that, this is … shit big shit!
instead of complaining and swearing do something concrete like funding the LibO project. see this link: https://freedomsponsors.org/ P.S. I cleaned the whiteboard from redundant information and added regression to the keywords since you said the bug was not present in 4.4.3.2. the fact the bug is still NEW implies it's still reproducible with latest 5.0.x releases so there's no need to clutter the whiteboard
Missing test file so I'm closing this as INVALID. Bug reports without public reproducers are more or less unusable.
resolved in Calc Version 5.2.1.2