After upgrading from version 3.4.5 to version 3.5.0rc3, I'm experiencing a significant time lag (2 to 3 seconds) when editing cells in a regularly used spreadsheet (with around 2500 rows and around 9 columns, but no calculations - it's just a list, but with various formatting applied to many of the cells). After opening, there is no lag when clicking in the 1st cell to be edited, only with the second and subsequent cells. I wouldn't describe the laptop involved as fast, however this lag never occurred in version 3.4.5. Defragmenting the hard drive made no difference. Other operations (saving, sorting, etc), seem unaffected.
Further to my initial report, I've now been able to compare performance on faster hardware under Windows 7. Using 3.5.0rc3 there is a small lag (noticeable but unimportant - a couple of tenths of a second) when editing cells in the spreadsheet concerned. In version 3.4.5 there is no detectable lag at all on the same hardware. It is therefore probable that this lag is related to computer performance rather that to Windows XP, however version 3.5.0rc3 has degraded performance and remains unusable for my purposes on my XP machine. Since XP is still the World's most popular operating system (and probably runs on older hardware), this is a serious bug.
I have a similar problem on upgrading from 3.4.5 on Windows 7 (64 bit). The spreadsheet has a graph. When any cell is updated in 3.5.0 final release the CPU hits 100% for a _very_ long time (many minutes) and, understandably, my system does not respond. When removing 3.5.0 and re-installing 3.4.5 there is no such behaviour.
Created attachment 58869 [details] Formatted spreadsheet for testing purposes This file contains only formats - no 'data' - but still exhibits the time lag issue.
Having just tested version 3.5.1 on my fast PC under Windows7 64bit, I can now report that the performance is worse than it was for version 3.5.0, with a delay of between 0.5 and 1 second to edit the fields. Not yet tested on the older laptop under XP. Sample file uploaded for replications test. Could this somehow be related to the newly introduced 'unlimited number of rules for conditional formatting' feature?
Have now tested on version 3.5 under Ubuntu and get a lag of around 1 second using the demonstration file on a reasonably fast PC. Since it's now a problem under 3 operating systems I'm changing this to affecting 'All' platforms.
reproduced in 3.5.2 on Fedora 64 bit and 3.5.0 on Windows XP 32 bit Considerably slower than in 3.3.4 and 3.4.3 versions
Great bug :-) can someone install debuginfo packages under Linux, and run the latest libreoffice 3.5.x under callgrind: cd /path/to/soffice.bin sudo chmod a+w . export OOO_DISABLE_RECOVERY=1 valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin -writer --splash-pipe=0 When it starts up (beware very slow ... ;-) then trigger the problem multiple times - say 10x or so (so as to swamp the startup profile), exit cleanly, gzip and attach the callgrind.1235.out. That should make it -far- easier to find & fix quickly. Thanks ! :-)
Bug 47986 sounds related.
Bug 47986 mentions that with LibO 3.5.3 the problem is gone. @Max: can you please try 3.5.3? Thanks.
@Eike Rathke Have only tested 3.5.3 on my fast Win7 64bit machine, but the problem remains the same - about a 1 second lag on every cell.
@Eike Rathke - a test file is available for testing - see attachments.
Problem seems to be formatting / cell attributes. Taking this.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c5064d3bd57a0d5e57e188274d74d61a3ac9922 resolved fdo#46160 query model only once whether it is a preview
Thanks for fixing this bug
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=52fc5dc51fc3f5f8cf212898e45fc90066fa7f8d&g=libreoffice-3-5 resolved fdo#46160 query model only once whether it is a preview It will be available in LibreOffice 3.5.4.
Thank you Eike Rathke for fixing this bug.
*** Bug 47986 has been marked as a duplicate of this bug. ***