[Libreoffice-bugs] [Bug 133131] Memory should be freed sooner after closing a document with tracked changes on (takes a minute or so)
https://bugs.documentfoundation.org/show_bug.cgi?id=133131 Mike Kaganski changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #3 from Mike Kaganski --- (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! -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 133131] Memory should be freed sooner after closing a document with tracked changes on (takes a minute or so)
https://bugs.documentfoundation.org/show_bug.cgi?id=133131 --- Comment #2 from Telesto --- (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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 133131] Memory should be freed sooner after closing a document with tracked changes on (takes a minute or so)
https://bugs.documentfoundation.org/show_bug.cgi?id=133131 --- Comment #1 from Mike Kaganski --- 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. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
