Description: Memory is released slowly when copying a large dataset first and small afterwards Steps to Reproduce: 1. Open the file found here: https://yadi.sk/i/rM9QctDym5y3M 2. Open a the task manager and monitor the memory usage 3. Copy columns A-C 4. Copy cell A1. Actual Results: LibO5.0 releases all the memory instantly after copying the small dataset (cell A1). I takes a while with LibO5.1 Expected Results: Should be as as fast as in LibO5 in my opinion. This probably will create issues when running multiple instances of Calc and copying back and forwards Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 6.0.0.0.alpha1+ Build ID: 13c5dd1d98a480cb01ca8f24242c80e326e4ade8 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-10-30_23:52:07 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 137412 [details] Bibisect log Bisected to: author Markus Mohrhard <markus.mohrhard@googlemail.com> 2015-10-01 05:38:47 (GMT) committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2015-10-01 05:38:47 (GMT) commit 6e8e898acb9f6825104f01d090f447e8dfc7e4a2 (patch) tree 487707d3afb5c1da6e3e87869f48c99162f28538 parent 4f1dca5083c5a301181786b563b165f19a9dec7f (diff) Revert "by default use the system memory allocator" It seems that even on Linux the system allocator is worse than our internal allocator. e.g: http://perf.libreoffice.org/perf_html/chitest_of_cppu_sc_on_vm139.details.html
Wrong bibisect results; commit is revert.
Created attachment 137418 [details] Screencast LibO6
Created attachment 137419 [details] Screencast LibO5.0.0.0alpha1+
Created attachment 137466 [details] Bibisect log Bisected to: author Eike Rathke <erack@redhat.com> 2015-09-08 11:59:57 (GMT) committer Eike Rathke <erack@redhat.com> 2015-09-08 12:02:22 (GMT) commit 37a36671e0abfa0e1dfd2cfdd6470a3f2805b199 (patch) tree 191ff35cdf8521c8903c983ad01125c3e3cd9b97 parent 7df729da30f89ad20cd5705e3a1a91866ac71898 (diff) reactivate fixed mempool for ScFormulaCell ... it got lost with 8b252f30267d043522ff2cbf2bf42275bb7a6ec6
I confirm, but I will leave it to Eike to comment on whether this is a problem or not. Version: 6.0.0.0.alpha1+ (x64) Build ID: 7e03c4eed72452fdfb87341214a21956c08ba969 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-26_00:58:29 Locale: fi-FI (fi_FI); Calc: group
No repro with Version: 6.0.0.0.alpha1+ Build ID: c24c32bf71b8e64bd0d36e511f554e1f6c015842 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-11-22_23:15:41 Locale: nl-NL (nl_NL); Calc: CL
(In reply to Telesto from comment #7) > No repro with > Version: 6.0.0.0.alpha1+ > Build ID: c24c32bf71b8e64bd0d36e511f554e1f6c015842 > CPU threads: 4; OS: Windows 6.3; UI render: default; > TinderBox: Win-x86@42, Branch:master, Time: 2017-11-22_23:15:41 > Locale: nl-NL (nl_NL); Calc: CL True for me as well. I think we should close and be happy. Version: 6.0.0.0.alpha1+ (x64) Build ID: a0ebba3d8855fee0bcec04a10137ae3a4f9f0e77 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-11-22_05:59:17 Locale: fi-FI (fi_FI); Calc: group threaded