Trying to work with the attached document results in huge visible lags. Lags happen on redrawing of the Calc window (for example, while hovering other window over it). At the time of redrawing soffice.bin consumes 100% of CPU. Test platform was Ubuntu 14.10 x64, LO version 4.3.3.2, CPU Celeron 1.8 GHz (Dual core), 2Gb RAM, AMD Radeon HD6230 (fglrx driver). Opening the same document on the same test platform with Crossover Office + MS Office 2007 works quite fine, at least notably better than LibreOffice. Therefore considering this as a bug.
Created attachment 109148 [details] File with issue
Confirmed: Ubuntu 14.04 x64 LibreOffice 4.3.2.2 release Marking as: New (confirmed) Minor - can slow down professional quality work but not prevent it Low - this is one test case which is incredibly hard to use to fix anything @Senya - if you could strip this document down as much as possible and still see the same problem. As is the document is pretty useless in determining what the problem is (the more complex a document, the less useful for triage purposes). Either way - valid bug report, marking as NEW.
Well, if it is complexity itself causes the bug, then stripping the document down will lead to the problem become unnoticeable. I suppose that lags are caused by cumulative perfomance slowdowns. Maybe we can use some profiling tools to find out what part of LO consumes most of resources with that document?
yes - I agree that it's the complexity causing the problem, just would be best to narrow it down as much as possible. There is no tool as far as I know that can look at cpu cycles and determine what lines in 10,000,000 lines are causing the hiccups. For memory usage there is (valgrind). If this is as simple as you can provide, then that's fine, but just wanted to point out that the more complex the less useful because you are right...it's likely a series of problems that are combining to cause the lag - and thus in reality if at all possible, each one should be reported separately. That being said, I've confirmed the lag so it's in NEW status. Thanks again!
I wonder whether it is possible to analyze it with gprof tool. Though I unfortunately have no time right now to play with it.
Hi @senya, there are a lot of COUNTIF(), a function that use regular expressions. @Joel ask for a simple case, but in this case the problem is only visible with hard spreadsheets with function using regular expressions, that need a bit of time for calculations. I think a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=79892 Please if you are not agree reopen it. *** This bug has been marked as a duplicate of bug 79892 ***
@senya, as the COUNTIF() seems in your file don't use regular expressions in the conditions, I think it's easy replace it with other simple formula. Please test replacing all COUNTIF and COUNTIFS in this way: October15.C46: =COUNTIFS(AU$6:AU$39;"<=8") with October15.C46: =SUMPRODUCT(AU$6:AU$39<=8) October15.D46: =COUNTIFS(AY$6:AY$39;"<=8";BA$6:BA$39;">=9") with October15.D46: =SUMPRODUCT(AY$6:AY$39<=8;BA$6:BA$39>=9) Also you cand disable Menu/Tools/Cells/Autocalculate, and do it manually with [F9] or more secure with [Shift]+[Ctrl]+[F9]
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/dc73583573a31078c8408e820d749aaeab25bc32%5E%21 crash-testing fdo86059-1.xlsx 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.