GNOME Bugzilla – Bug 648868
Slowdowns after insert/delete rows/columns
Last modified: 2011-08-11 23:19:12 UTC
Created attachment 186814 [details] Excel (xlsx) file to reproduce problem In relation to the attached test file: I wanted to edit some cells, delete some blocks of unneeded rows and columns, and remove the fancy formatting (colors and backgrounds). As my edits proceeded, gnumeric's performance degraded severely: after making (say) about 10 changes it took many seconds at 100% CPU usage to delete a few rows, or to save the file as gnumeric XML. Selecting all cells and doing /Format/Cells/Format... brought the program to a halt for about a minute.
I can't trigger this, but that may mean nothing more than I am not picking the right operations in the right order. From your description, I suspect that the style data has gotten fragmented. Column insert/delete has been observed to cause that, but never under controlled (== reproducible) circumstances. Note: save+reload re-optimizes the style information and things should go back to normal.
Morten, I can replicate consistently using the following sequence of row deletions: Delete row 50 Delete row 53 Delete rows 91/92 Delete row 105 Delete row 151 Delete row 153 Delete row 225 Delete row 226 where I always refer to the new row number. These are the light grey hatched rows. The last deletion on my machine takes about 45 seconds.
I also note that we encounter: Unexpected element 'extLst' in state : styleSheet Since this issue likely relates to styles this could be pertinent.
Created attachment 186831 [details] style-optimize log when loading changed file GNM_DEBUG=style-optimize optimize log. I see that slowdown too. It seems to be gradual. The attached log is from GNM_DEBUG=style-optimize loading the sheet that was saved after the deletion of the last row. We have piles of "col" tiles that should be simple.
Allin, a workaround for you is to reduce the number of rows. You are only using less than 300 but have 1M. If you reduce the number to something smaller you should not experience this slowdown.
Created attachment 186846 [details] [review] Tentative patch This fixes the problem, but I'm not sure I dare apply it in the stable series.
Note, that the patch has been committed, but is turned off with an "#if 0".
Now that we have branched we should probably enable the patch to allow for maximum testing before the next stable release.
Patch enabled in the developer's branch. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.