Created attachment 69053 [details] Sample document for slow calculation and saving I have some spreadsheets/tables in one Calc document each with about 500 values and simple calculation (+/-) plus additional formatting (background color depening on cell value; aka heatmap). Opening the file and calculation takes seconds, this is tolerable, but when I save the document it lasts for half an hour or more (resulting file has <500k).
Speed is normal without formatting.
This one looks rather similar to "Bug 54550 - FILESAVE particular document takes long time with max CPU load", might be a DUP @Heiko Tietze: can you see relationship of your document and the sample document in Bug 54550, what looks less formatted, but contains lots of Styles?
#54550 doesn't save at all. I my case it just takes a very long time, but it is finished. One thread of two available is working, i.e. 50% load ;-).
Hm, for me that other sample also saves ... Comparing Times for Save as (all: WIN 7 64 bit same machine): 3.4.1: < 10s 3.5.6.2: 12s 3.6.0.0α: < 10s 3.6.0.4: 60s 3.6.3.2: 120s So this problem seems new in 3.6 The α-Version I tested is: Server installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 475d0c5-829fc92-39746e8-206648e-fefd87]" (2012-02-14) I only watched that in 3.6.0.4: The Progress bar does a bad job. 45s invisible, then immediately to 100%, then it takes another 1/4 minute until LibO becomes responsive again. I also see that the later 3.6 Version need more time for FILEOPEN than the early ones, I can't tell whether that problem is related or not.
Okay, on Linux with a faster PC (probably it depends more on memory) saving times is as you write. I was running LO on a rather old notebook with W7 32bit where I actually went off after 15min processing and progressbar still at first third. We have not only an issue when saving formatted sheets but as well during use. Any operation is followed by a reevaluation, repaint, or whatever. When I click toolbar's first entry (file), it takes some seconds (~3s) to open the dropdown.
On Linux the doc pulls ~100% CPU (strange enough) when viewing the colorful Oxygen sheets (this is also on "Tango-Oxygen_HT" the case, even more strange), while 3.5.5 consumes 167MB 3.6.3 consumes 1.7GB (!) so that older notebook probably is continuously swapping..
Created attachment 72660 [details] file without conditional format I looked into it and the problem is that at some point the conditional formats where screwed up. This creates now problems with the new range based conditional formats. The easiest solution is to delete all conditional formats and define them new. This should fix all problems with the document and even improve the performance. The new range based solution for conditional formats allows to deal with large conditional formats easier. Using color scales for these coloring additionally improve the performance a bit more. Attached is a clean version of the file. If you can reproduce the problem after defining the formats new I'd like to know a step by step instruction to reproduce the problem. However I suspect the problem was either introduced much earlier as the old style conditional format information already show the problem, or with an early version of 3.6 that contained a bug in the transformation from old-style to new style conditional format information.
I don't know exactly what you have in mind with "new range based solution for conditional formats". But my complex formula with formatting works like a charm now (v3.6.4.3). Thanks a lot!
@Heiko A problem is FIXED if a known fix in a new version heals a problem that still exists with the document and older versions. @Markus: I think it's currently not intended to follow up work on a fix for the very particular problems in reporter's original sample document attachment 69053 [details]?
> @Markus: > I think it's currently not intended to follow up work on a fix for the very > particular problems in reporter's original sample document attachment 69053 [details] > [details]? As long as I have no way to reproduce this problem, which hopefully is not reproducible anymore, I can't fix it. So for now I'd assume that this bug is fixed already.
(In reply to comment #8) > I don't know exactly what you have in mind with "new range based solution > for conditional formats". But my complex formula with formatting works like > a charm now (v3.6.4.3). Thanks a lot! The old conditional format design until 3.5 was based on single cell styles. Therefore conditional formats where a cell property. Now since 3.6 conditional formats are range based, that means we store the information to which range a conditional format applies. This allows for more complex conditional formats like color scales and formats that take all the values in the range into account (see Libreoffice 4.0 for some more of them)
Migrating Whiteboard tags to Keywords: (perf) [NinjaEdit]