Bug 124098 - LibreCalc6.2: Opening a Calc with some formulas: It writes "adapt Row Height" which is taking ages to load!
Summary: LibreCalc6.2: Opening a Calc with some formulas: It writes "adapt Row Height"...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: x86 (IA32) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf
: 43804 56564 125499 140036 (view as bug list)
Depends on:
Blocks: File-Opening Regressions-row-height
  Show dependency treegraph
 
Reported: 2019-03-15 13:03 UTC by elias estatistics
Modified: 2021-09-02 20:04 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
OPs example file attached here to BZ (1.94 MB, application/vnd.oasis.opendocument.spreadsheet)
2019-03-15 14:24 UTC, V Stuart Foote
Details
test spreadsheet with large block of numbers (1.12 MB, application/vnd.oasis.opendocument.spreadsheet)
2021-08-28 19:33 UTC, casa
Details
Example file (351.07 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-09-02 07:31 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description elias estatistics 2019-03-15 13:03:44 UTC
Description:
LibreCalc: Opening a Calc with some formulas: It writes "adapt Row Height" which is taking ages to load!

See Kazam video and the Calc sheet itself. 

Note: this was opened very quickly in previous Libre Calc

ps.
Version: 6.2.1.2
Build ID: libreoffice-6.2.1.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: el-GR (el_GR.UTF-8); UI-Language: en-US
Calc: threaded

Steps to Reproduce:
1.open the calc sheet in atatchment in Libre Calc6.2
2.
3.

Actual Results:
Very slow to open a calc sheet with formulas

Expected Results:
Quick ope of the calc file. 


Reproducible: Always


User Profile Reset: No



Additional Info:

Version: 6.2.1.2
Build ID: libreoffice-6.2.1.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: el-GR (el_GR.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 elias estatistics 2019-03-15 13:05:58 UTC
Kazam Video of the process: https://upload.cat/9d2c64fe8efe70e0 
the Calc sheet itself: http://www.filedropper.com/a2means
Comment 2 V Stuart Foote 2019-03-15 14:24:21 UTC
Created attachment 149998 [details]
OPs example file attached here to BZ

Processing this large sheet on Windows is no faster, also gets held up with "adapt row height" processing.

Noticeable difference in handling between recent master/6.3.0alpha0+ and the 6.2.2.1 release build

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Version: 6.2.2.1 (x64)
Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 3 V Stuart Foote 2019-03-15 14:33:32 UTC
better in master, but still issue. On same system with 5.3.7.2 opened without "adopt row height" processing.

Version: 5.3.7.2 (x64)
Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group
Comment 4 elias estatistics 2019-03-15 17:57:15 UTC
Here, Kazam video from opening the same file in Libre Office6.1.5.2

It takes less than some seconds 16  seconds vs 93seconds! ! Huge difference!  

video: https://ufile.io/rsb0j


ps.

Version: 6.1.5.2
Build ID: 1:6.1.5~rc2-0ubuntu0.18.04.1~lo3
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; 
Locale: el-GR (el_GR.UTF-8); Calc: group threaded
Comment 5 Oliver Brinzing 2019-03-16 12:46:36 UTC
i checked with my notebook (Win10Pro x64, Core-i5-3320M 2,6GHZ,8GB, 256GB SSD) and settings:
- OpenGL/OpenCL:             disabled 
- Recalculation on File Load [Always recalculate]
- CPU threading settings:    disabled

LO 5.4.7.2: ~40s
LO 6.0.7.3: ~40s
LO 6.1.5.2: ~65s
LO 6.2.2.1: ~65s
Comment 6 V Stuart Foote 2019-03-16 16:16:27 UTC
So, if I force sheet to not update row heights--it loads immediately after calculating formula values.

A work around, but done by:

1. opening sheet

2. cursor focus into a cell with default row height (I used the first cell under the Indexing tables column)

3. select All cells

4. apply format from main menu Format -> Rows -> Height (the value shows 0.21 ")

5. save to a new ODS file

Open the newly saved version.  Seems the SC doc shell then does not call the SetOptimalHeight() or SetOptimalHeightOnly(), and so the document opens to screen with no delay after "calculating" of cell formulas completes. Speed is restored, but lose "optimal" font resize to fit results.
Comment 7 Kevin Suo 2019-05-01 09:48:16 UTC
bibisected using the bibisect-linux-64-6.2 repo:

5d007cfc8733799cf0535eac3e482eb8cae4b908 is the first bad commit
commit 5d007cfc8733799cf0535eac3e482eb8cae4b908
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Jun 8 00:50:11 2018 +0200

    source sha:1e55a47e89a9d9d6cf9cb3993484022aaf2c097b

author Vasily Melenchuk <Vasily.Melenchuk@cib.de> 2018-04-06 20:19:10 +0300
committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2018-06-08 00:47:06 +0200
commit 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
tdf#62268: allow row height recalculation on document load
During document load rows with style:use-optimal-row-height="true" should recalculate it's height.

Adding Vasily Melenchuk to CC, would you please take a look.

git bisect log
# bad: [8b2cf76950e32ea46ff293ce75177841ad920e38] source sha:1149d20ce9f8682b58f98d3fa3bf289fc5974087
# good: [f741463dfe1900d3acf87b538c0c043e42bc523d] source sha:3a801799536e6870f2fb111b1cc00b9575a35a39
git bisect start 'master' 'oldest'
# bad: [f2a6a57cb2d0fbe45c9cfafdcf33a816c6ced63f] source sha:da8617d69a7b27a3eeb3f26e207ddf1b4de3eeb3
git bisect bad f2a6a57cb2d0fbe45c9cfafdcf33a816c6ced63f
# bad: [78b09b863133636196066d09bd1098bfd320b0e5] source sha:064c86b817c5d122af13f1bde26b51a992bf1fd9
git bisect bad 78b09b863133636196066d09bd1098bfd320b0e5
# bad: [350471d334577c65ef95c1ea1799eb8e83b340bc] source sha:2c85607101e2e04e870e3b87362f39f9a9148e6c
git bisect bad 350471d334577c65ef95c1ea1799eb8e83b340bc
# good: [6ba40cbc247af171132dc96e7e110c3b73c1e32a] source sha:18a8cac57d5450fef9111fa356839f07c7593ad0
git bisect good 6ba40cbc247af171132dc96e7e110c3b73c1e32a
# bad: [458d44d3be1e40259a480a7bbd2acce49d2df3f9] source sha:ba8c14f488a0bf9f1b10b5f1a24a367b8b98caf6
git bisect bad 458d44d3be1e40259a480a7bbd2acce49d2df3f9
# bad: [e5b96fbf312c88038a5109cd5a2cc1f7e931fed4] source sha:6c41b664cca6d6985b6f619f83cd103206c5a109
git bisect bad e5b96fbf312c88038a5109cd5a2cc1f7e931fed4
# bad: [12c296faec160c1166ae71e610cdb8778f3ec4af] source sha:8fef261588c40b8bd85395650afbaf0c9dbdac72
git bisect bad 12c296faec160c1166ae71e610cdb8778f3ec4af
# good: [45ee446cead7f889e05cc3f73738285faa78fb56] source sha:6b8915816242215208e1bb18cfbf01ae85619c46
git bisect good 45ee446cead7f889e05cc3f73738285faa78fb56
# good: [13760daeb59ff9bd2e4ecc973e108fea7a418b55] source sha:fccc7aebb5285e36530b14001e37b33b586365f9
git bisect good 13760daeb59ff9bd2e4ecc973e108fea7a418b55
# bad: [3bdbc761ffeaf9fbd913659c0499568e123d1ed2] source sha:f81714d8e70569506bd10cffc9dc6c18d7c6966f
git bisect bad 3bdbc761ffeaf9fbd913659c0499568e123d1ed2
# bad: [5d007cfc8733799cf0535eac3e482eb8cae4b908] source sha:1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
git bisect bad 5d007cfc8733799cf0535eac3e482eb8cae4b908
# good: [a3266d604bbc628c822dd1dde60bde3004fbd9fd] source sha:b9dde4a74cba5a771cbc85880d518f6717d19216
git bisect good a3266d604bbc628c822dd1dde60bde3004fbd9fd
# good: [2fee85293f3c389834856f15f96e86ff537cee82] source sha:2a7f74900fb646235b74d4c9bd4690e44edc3ed4
git bisect good 2fee85293f3c389834856f15f96e86ff537cee82
# first bad commit: [5d007cfc8733799cf0535eac3e482eb8cae4b908] source sha:1e55a47e89a9d9d6cf9cb3993484022aaf2c097b

----
MORE INFO:
with a dbgutil build on master today, when open this file I get the following warning in terminal:
warn:sc:9128:9128:sc/source/filter/orcus/orcusfiltersimpl.cxx:149: Unable to load styles from xml file! failed to load
Comment 8 V Stuart Foote 2019-05-01 14:18:44 UTC
So does fix for bug 62268 need revisit? 

Seems if all rows with cells are assigned the "style:use-optimal-row-height='true'" we're doing the correct thing of parsing each row before rendering.

Isn't issue then that all rows of a close to empty sheet receive that style as default? It sets them to default, but parses each for cell content--expensive.

Simple fix might be to change default row style to "style:use-optimal-row-height='false'"--and only explicitly set it for rows with cell content?
Comment 9 Xisco Faulí 2019-05-27 11:42:45 UTC
*** Bug 125499 has been marked as a duplicate of this bug. ***
Comment 10 pharmankur 2019-11-15 10:11:33 UTC
Still present in latest libreoffice

My 5 MB calc file take 45 min to load completely (Intel© Core™ i3-3110M CPU @ 2.40GHz × 2 with 4 GB RAM )

Tried with Linux Mint 19.1 & LO 6.3.3
Comment 11 Oliver Brinzing 2019-11-15 18:20:21 UTC
i checked with my notebook (Win10Pro x64, Core-i5-3320M 2,6GHZ,8GB, 256GB SSD) and settings:
- OpenGL/OpenCL:             disabled 
- Recalculation on File Load [Always recalculate]
- CPU threading settings:    disabled

Version: 6.1.6.3 (x64)
Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: 

Version: 6.2.8.2 (x64)
Build-ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

Version: 6.3.3.2 (x64)
Build-ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

all versions need ~65 sec to load

but 

Version: 6.0.7.3 (x64)
Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: 

needs only ~40 sec
Comment 12 V Stuart Foote 2019-11-15 18:57:42 UTC
@Eike, Kohei -- do you have any thoughts for use of "style:use-optimal-row-height='true'" so it would not be as expensive as it is now?
Comment 13 Mike Kaganski 2020-01-19 12:45:23 UTC
The recalculation of heights effectively performs full recalc (so it takes the same time Ctrl+Shift+F9 take). This makes cached values in own format useless.
Comment 14 Thorsten Behrens (allotropia) 2020-02-16 13:22:44 UTC
I believe the underlying problem is that Calc would somehow assign style:use-optimal-row-height='true' to all & sundry. I *think* we had that fixed at some stage, at least cannot repro with some simple documents anymore in 6.4.

Any second thoughts on that? If the above is *still* an issue (perhaps with a more complex setup), I'd love to hear.
Comment 15 Xisco Faulí 2020-02-20 10:34:01 UTC
putting it back to NEW ( NEEDINFO status is incorrect here )

Before 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b the issue can also be reproducible if recalculation on File Load for
ODF files is set to Always Recalculate in Tools/Options.../LibreOffice
Calc/Formula

in

Version: 6.0.0.0.alpha1+
Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

it takes

real	2m26,267s
user	2m20,015s
sys	0m3,418s

with the option enabled and

real	1m6,187s
user	0m54,940s
sys	0m7,024s

with it disabled
Comment 16 Xisco Faulí 2020-02-20 10:38:00 UTC
For the record, it takes

real	2m26,906s
user	2m24,253s
sys	0m2,676s

in

Version: 7.0.0.0.alpha0+
Build ID: bc994a4b01cf61444452bb377010c7c4cc377698
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 17 Xisco Faulí 2020-02-20 10:46:46 UTC
and

real	2m38,464s
user	2m29,478s
sys	0m5,677s

in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.19; Render: default;
Comment 18 Xisco Faulí 2020-03-25 13:09:40 UTC
*** Bug 56564 has been marked as a duplicate of this bug. ***
Comment 19 Telesto 2020-05-17 11:12:21 UTC
Increasing priority.. 
* Not good for the general impression.. 
* Obvious since LibreOffice 6.2
Comment 20 Telesto 2020-06-05 16:07:05 UTC
1. Open attachment 142401 [details] (XLSX)-> Opens fine
2. Save to ODS & reopen..
Comment 21 Telesto 2020-06-07 19:50:35 UTC
Another one: attachment 154545 [details]
Comment 22 elias estatistics 2020-06-16 19:34:09 UTC
I am the same person that I opened this bug. 
I downloaded LibreOffice dev 7. The problem remains. 
It took almost 2 whole minutes to open it! 

ps. 
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: el-GR (el_GR.UTF-8); UI-Language: en-US
Calc: threaded

Example ods File which remains for 30 days for download: https://ufile.io/qc3zs2ra
Comment 23 Vasily Melenchuk (CIB) 2020-07-24 08:26:21 UTC
In given document we have tons of rows with style:use-optimal-row-height="true" and these rows should be recalculated to find this optimal height. Once I remove this style from rows document begin to load in acceptable time. So feature works okay from technical point of view.

At the same time attempts to set optimal height from UI also very slow. Maybe it requires some profiling & optimization.

While this is quite often case (this value is set by default in many cases) it makes sense to adjust adaptation of row height on load further. Out of my head I see several options:
* provide per document setting enabling or disabling this feature. With disabled by default we will receive less such problems like current one.
* do not calculate on load rows with style:use-optimal-row-height="true" and provided row height. Such scenario should be okay for at least one of original tdf#62268 bugdocs.

IMHO row recalculation on load is quite handy only for generated by third-party tools documents. For documents created in Calc it senseless: given height is correct one (otherwise it is a bug). So for generated docs users should just omit style:row-height parameter to force LO to calculate this row height on load.
Comment 24 François 2020-07-30 12:35:43 UTC
It's even worse here.

I have a document with just a few rows set to "style:use-optimal-row-height='true'" and LO refuses to open the document. It simply crashes.

We are running under macOS 10.14.6 and 10.15.6 and we can confirm that it happens with any version of LO > 6.1.6.3

Hope you get this fixed very soon :)

Please let me know if I can help somehow.
Comment 25 François 2020-07-30 16:09:22 UTC
Quick follow-up :

I've done some more testings all this afternoon.
After messing a bit with the file with LO 6.1, I finally managed to remove some lines where `style:use-optimal-row-height="true"` was applied...

Which led me to being able to open the file with the latest LO (6.4.4.2) - hurray !
Unfortunately, it's then impossible to save the file : LO crashes (no report, no log :-/ ).

Is it recalculating the rows height when saving ? (or do I have to look somewhere else ?)
Comment 26 PremPa 2020-08-08 15:08:29 UTC
I'm not able to find which lines have `style:use-optimal-row-height="true"` 

But I think it's more "friendly", especially for low profile users, to add the possibilty to switch that off by some option.

Just my two cents.
Comment 27 PremPa 2020-09-29 12:39:10 UTC Comment hidden (no-value)
Comment 28 Junior Polegato 2020-10-20 18:52:11 UTC Comment hidden (off-topic)
Comment 29 Xisco Faulí 2021-02-23 09:48:29 UTC
*** Bug 140036 has been marked as a duplicate of this bug. ***
Comment 30 Roman Kuznetsov 2021-04-14 19:35:15 UTC
it takes 44 sec in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL
Comment 31 V Stuart Foote 2021-07-30 12:41:43 UTC
(In reply to Roman Kuznetsov from comment #30)

opening attachment 169330 [details] ODF archive and editing the content.xml to change the two row styles from 'use-optimal-row-height="true"' to "false" -- the sheet opens in about 5 seconds. With them intact in the original open in 18 seconds.

Kevin Suo gives possible approach to fix the regression caused by work on bug 62268


Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: cb2827f5f65324f309fa0e3c30d0b19ad237410e
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 32 Thorsten Behrens (allotropia) 2021-07-30 15:15:31 UTC
Does anybody have any pointers on the history why Calc sets this use-optimal-row-height="true"' for all rows in a new document?

FWIW, multi-line Calc cells are one possible reason. Create one, type some text so you get e.g. 3 lines (enable Alignment -> Wrap text automatically) - then change zoom value & see the text line breaking change randomly.

How is a Calc user supposed to generate a document with a row-height that exactly matches the needed area, if the row height is not adapted on load then?
Comment 33 V Stuart Foote 2021-07-30 16:43:49 UTC
(In reply to Thorsten Behrens (allotropia) from comment #32)
> Does anybody have any pointers on the history why Calc sets this
> use-optimal-row-height="true"' for all rows in a new document?
> 

Nope, and seems unnecessary/non-performant to have it applied to all rows with the style during load.

> FWIW, multi-line Calc cells are one possible reason. Create one, type some
> text so you get e.g. 3 lines (enable Alignment -> Wrap text automatically) -
> then change zoom value & see the text line breaking change randomly.
>
> How is a Calc user supposed to generate a document with a row-height that
> exactly matches the needed area, if the row height is not adapted on load
> then?

Mixing apples and oranges? Not so sure as the scale on zoom is clean if you enable the Calc general option 'Use printer metrics for text formatting'. Otherwise the recalculate 

While the tweak done for bug 62268 ( https://gerrit.libreoffice.org/c/core/+/52521/ ) to always process use-optimal-row-height="true" on load is causing the annoyance of slow opening.

Wouldn't Kevin's test ( as on https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c38 ) be a reasonable adjustment to correct this?
Comment 34 V Stuart Foote 2021-07-30 16:47:23 UTC
(In reply to V Stuart Foote from comment #33)
> Otherwise the recalculate 

does not hold the cell content at scale when zooming in or out, and hides or shifts it.
Comment 35 Kevin Suo 2021-07-30 16:59:04 UTC
(In reply to Thorsten Behrens (allotropia) from comment #32)

See 
https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c46

In short: by default each row has style:use-optimal-row-height='true'. When you type multiline content in a cell and hit enter, then style:row-height is updated. For style:use-optimal-row-height='false' when you type multiline content the style:row-height is not updated, so that it uses default row height or the old value. In both cases on FILEOPEN the correct style:row-height is used directly, no need to recalculate.
Comment 36 Eike Rathke 2021-08-06 18:39:18 UTC
I didn't wrap my head around, neither any possibly underlying problems nor the proposed solution, but the procedure described in https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c12 and mentioned again in https://bugs.documentfoundation.org/show_bug.cgi?id=62268#c47 sounds reasonable to me on first sight.

Citing here for completeness:

a) if there is no height attribute and the "use_optimal-row-height" attribute is set then calculate the row height

b) if there is no height attribute and the "use_optimal-row-height" attribute is not set then use the default value

c) if there is a height attribute just use it
Comment 37 Xisco Faulí 2021-08-10 16:16:26 UTC
This is not a regression, see comment 15
Comment 39 Mike Kaganski 2021-08-11 12:02:54 UTC
(In reply to Xisco Faulí from comment #37)
> This is not a regression, see comment 15

This *is* a regression.
In comment 15, you point to the fact that *forced recalculation* takes just as much. But that is not the issue raised here; the low performance of the recalculation itself is a separate issue. Yes, *if* that separate issue were fixed, and recalc took an instant, this issue would *possibly* be also resolved (unless there is another reason to restore cached height even if recalc doesn't take long). But this specific issue is about the problem that had appeared after the commit identified in comment 7, and is specifically about the new behavior of ignoring the cached values, and taking that long time, where it *did not* previously: on file open.
Comment 40 casa 2021-08-28 19:33:48 UTC Comment hidden (off-topic)
Comment 41 casa 2021-08-28 19:35:05 UTC Comment hidden (off-topic)
Comment 42 casa 2021-08-28 19:41:13 UTC Comment hidden (off-topic)
Comment 43 V Stuart Foote 2021-08-28 19:52:54 UTC
*** Bug 43804 has been marked as a duplicate of this bug. ***
Comment 44 Mike Kaganski 2021-08-28 20:24:21 UTC Comment hidden (off-topic)
Comment 45 casa 2021-08-28 20:35:17 UTC Comment hidden (off-topic)
Comment 46 casa 2021-08-28 21:01:01 UTC Comment hidden (off-topic)
Comment 47 Telesto 2021-09-02 07:31:04 UTC
Created attachment 174723 [details]
Example file

FWIW I bisected the example file above to this commit and a slow calculation bug 144257, which might be related to (re)calculation performance issue (see comment 39)