Bug 133131 - Memory should be freed sooner after closing a document with tracked changes on (takes a minute or so)
Summary: Memory should be freed sooner after closing a document with tracked changes o...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-17 19:51 UTC by Telesto
Modified: 2020-05-18 04:59 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-17 19:51:38 UTC
Description:
Memory should be freed sooner after closing a document with tracked changes on

Steps to Reproduce:
1. open Calc
2. Tools -> Options -> Advanced -> Open Expert Configuration -> Search for Undo
Set undo steps 100 back to 0
3. Close LibreOffice and restart
4. Open the attachment 160938 [details]
4a Enable tracking changes
5. Copy Column D
6. Start pasting column by column from E to S
7. Memory usage increase to 1,5
8. Reject all changes -> Memory builds up to 1,9 GB
9. Close the document -> 600 MB left -> wait a minute or so.. drops back to 189 MB


Actual Results:
Memory is released slowly

Expected Results:
Memory should be released after close of the document in question (if possible)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha1+ (x64)
Build ID: f9790da286f2d2fa47f1748f8cfa6172c6622ca3
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: de-CH (nl_NL); UI: en-US
Calc: CL
Comment 1 Mike Kaganski 2020-05-17 20:15:14 UTC
I am very skeptic about this issue. I suspect a case when that's OS using its own reasoning when to free its caches. OS memory management is not something an application should tweak without a really good reason. So first of all - which *problem* is experienced here? Some *numbers* changing in some counters in some moments and not in other moments is not a problem by itself.
Comment 2 Telesto 2020-05-17 21:01:38 UTC
(In reply to Mike Kaganski from comment #1)
> I am very skeptic about this issue. I suspect a case when that's OS using
> its own reasoning when to free its caches. OS memory management is not
> something an application should tweak without a really good reason. So first
> of all - which *problem* is experienced here? Some *numbers* changing in
> some counters in some moments and not in other moments is not a problem by
> itself.

I'm not an expert on memory management.. Which part is done by the programmer, which part by compiler and the OS. So it's hard to look for something 'workable'.
However, Calc is really loving to consume memory.. So it's not hard to use up 8 GB of ram (the limit for me, less actually). And if it loves to hold on to it for a while it can be come unworkable.. 

Why it uses so much memory is a mystery at itself.. The memory footprint of Excel doing the same thing is substantial lower .. Again.. not qualified for comparison.. 

But feel free to close.. the only thing I observe is that closing a document doesn't release the memory for quite some time for a - for me - unknown reason.
Comment 3 Mike Kaganski 2020-05-18 04:59:39 UTC
(In reply to Telesto from comment #2)

To clarify: trying to lower memory consumption is a great things itself. If we can change memory requirememns, e.g. using more efficient structures etc, that would be most welcome.

However, the specific issue was not filed against *too much memory was required for a specific task*; it was about the *timing* how the memory was freed after initial allocation and closing the data. This aspect should not be generally considered a bug, unless there is a substantial evidence that it causes real problems. Of course, if memory is not freed at all, that should be considered a bug, though; again, I say about dynamics here, when it *is* released, but not at the moment when you expected, which means it is handled correctly, but using a strategy different from your expectations.

I hope it makes my response clearer. Sorry if I wasn't specific enough.

Closing NOTABUG for the time being; of course feel free to reopen in the event that you see a real problem caused by the behaviour you reported. Thank you!