OK, as requested I'm putting in a feature request. As reported in 43008, if a user attempts to paste a single value into a whole column, it takes a very long time to do it: to a naive user it appears to hang. I agree that it's not a bug. Libre Office is entitled to do whatever its developers specify it to do. However if it does something like this when the other well-known spreadsheet (MS Excel) performs this operation effectively instantly, this is at least a significant inconvenience to users and a deterrent to users from migrating to LO Spreadsheet. Even if it isn't actually a bug, it looks like a bug and it walks like a bug and it quacks like a bug. I could argue that it is a specification error although not an implementation bug. This situation is made a bit worse by the fact that if you copy a column in LO and paste it over another column, it does this instantly: I presume you are smart enough to only paste the cells that have something in them. This gives users a reasonable expectation that pasting something into a column should happen quickly. If I recall correctly, pasting a format into a whole column is also done quickly: only pasting data into a whole column is slow. I don't know how MS Excel does a paste of a single number into a column so quickly. My guess is that it has some sort of notion of the default value in a column, and it only overwrites that and then redraws the cells which are visible. Presumably it would require significant surgery to make LO do this. You have to deal with the same case for rows and consider what happens to a cell whose row and column both have (different) defaults. This still wouldn't deal with the problem of pasting a block of cells into one or more columns: I don't know if MS Excel does this quickly since I don't use it any more. So my feature request is to do something other than tying up the processor for a long time when the user requests a paste into one or more whole columns or rows. My *preferred* solution would of course be to do it quickly since this is what users really want. If the developers don't feel that it is worth the work required, then a fallback solution would be to put up a dialog box with some sort of estimate of how long it will take, and ask the user if they really want to do it.
Hello, tested with string/numerical values - paste into whole column is in few seconds - no bug here. Copy rows with formula A1=1 A2=2 A3=A1+A2 program freeze, high CPU etc. Tried with excel - copy string/numerical values is the same behaviour as in Calc. - Copy rows with formula A1=1 A2=2 A3=A1+A2 excel copy only this three cells.
Hi. Something else is needed. A logger plug-in that monitor performance in that kind of situation in order to write better bug reports and confirm the defect.
(In reply to rinvel from comment #2) > Something else is needed. > A logger plug-in that monitor performance in that kind of situation in order > to write better bug reports and confirm the defect. Hi Rinvel, We do have tools for debugging LibreOffice: https://wiki.documentfoundation.org/Development/How_to_debug Whiteboard -> perf (In reply to Richard Parkins from comment #0) > I don't know how MS Excel does a paste of a single number into a column so > quickly...Presumably it would require significant surgery to make LO do this. I'm not sure, but yes, it could take a lot of time to fully-implement this feature. > a fallback solution would be to put up a > dialog box with some sort of estimate of how long it will take, and ask the > user if they really want to do it. Creating the dialog box would be easy; deciding when an operation will take a long time will be harder. No guarantees that this "fallback" solution will be an easy fix. At the end of the day, we'd really like to avoid LibreOffice hanging due to basic user operations such as cut and paste. So status -> NEW.
We need is an easy-to-use extension for end user : the methods you provided are for developers not for end users. We also need to consolidate all the duplicate bugs that report the problem. Each one is a different way to reproduce the bug.
(In reply to raal from comment #1) > Hello, > tested with string/numerical values - paste into whole column is in few > seconds - no bug here. Raal -- take a look at the repro steps in bug 68156 comment 9. (In reply to rinvel from comment #4) > We need is an easy-to-use extension for end user : the methods you provided > are for developers not for end users. I'd love to have powerful tools that are built for end users, but I don't know of any that would help in this case. Right now, the developer-centric tools are our best bet at tracking-down performance issues. > > We also need to consolidate all the duplicate bugs that report the problem. > Each one is a different way to reproduce the bug. Bug 43008 has a couple of dupes, but at first glance they all look similar. To keep things simple, I'd either stick with the repro steps we have, or make a short comment pointing at the repro steps in other report comments (as I did in this comment above)
Does LO have a log / an error log / a dump file / a verbose mode we could use or activate ? In the case of a problem the file could then be audited.
(In reply to rinvel from comment #6) > Does LO have a log / an error log / a dump file / a verbose mode we could > use or activate ? If you run LibreOffice in a terminal, you can see some error output useful for debugging. > > In the case of a problem the file could then be audited. Sure, but how would such a file help in this case?
(In reply to Robinson Tryon (qubit) from comment #5) > Raal -- take a look at the repro steps in bug 68156 comment 9. FWIW, LO 3.3.0.4 is much snappier with the copy/paste in attachment 111136 [details] (testing on Ubuntu 14.04): (Approximate times) ------------------- 3.3.0.4: 8 sec 3.5.7.2: 15 sec 4.0.6.2: 15 sec 4.1.2.2: 60+ sec (Killed process) Perhaps LibreOffice could have a 'Cancel current operation' button? That way we wouldn't have to make a judgment call about whether an operation is taking a long time or the application has hung and will never finish.
> FWIW, LO 3.3.0.4 is much snappier with the copy/paste in attachment 111136 [details] > [details] (testing on Ubuntu 14.04): > > (Approximate times) > ------------------- > 3.3.0.4: 8 sec > 3.5.7.2: 15 sec > 4.0.6.2: 15 sec > 4.1.2.2: 60+ sec (Killed process) Thus the bug should be considered a Regression and not a feature request, shouldn't it?
(In reply to Teo91 from comment #9) > > FWIW, LO 3.3.0.4 is much snappier with the copy/paste in attachment 111136 [details] > > [details] (testing on Ubuntu 14.04): > > > > (Approximate times) > > ------------------- > > 3.3.0.4: 8 sec > > 3.5.7.2: 15 sec > > 4.0.6.2: 15 sec > > 4.1.2.2: 60+ sec (Killed process) > > Thus the bug should be considered a Regression and not a feature request, > shouldn't it? My guess is that some operations are taking longer because of increased complexity in the mechanisms underneath Calc. The time to perform certain operations has indeed increased, however I'm not sure if the Calc devs would see this as a regression. I'm going to mark this as a possibleRegression and let the devs weigh-in.
Migrating Whiteboard tags to Keywords: (possibleRegression, perf)
This bug starts wrong with title "Feature request following closure of bug 43008" and a lot of talk. There were a number of similar bugs and duplicates, but they are closed. It's next to impossible some dev will take this one with discussion that went astray and make a large Cal redesign. I'll close this bug. Whoever still finds and tests reasoning as valid, can open a new clean one, but please after reading all others. With succinct explanation, arguments and results.