Created attachment 145214 [details] sample Steps: 1. unzip 2. Open the Report.ods. enable content. Memory will hover between 300 and 350 mb. 3. On the Header sheet, change the value (1- 12) of cell C3 4. On the sheet Dashboard, press control + shift + f9 to hard calculate. 5. Monitor the memory usage for 10 mins. It will drop to 150 - 200 mb level. 6. Repeat step 3. memory will not increase. Expectation. Memory should not exceed 200 mb upon opening.
i can not find a "Report.ods" inside the attachted *.zip archiv. there is only a .~lock.Report.ods# inside. can you plaese add the file?
Created attachment 145249 [details] sample
Version: 6.1.3.0.0+ Build ID: 12b3395330953384bb80904fee489389db1e0cfc CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86@42, Branch:libreoffice-6-1, Time: 2018-09-23_16:09:50 Locale: en-PH (en_PH); Calc: CL under this version, I cannot replicate the ram usage. 6.1.3 is even faster in updating the external links. The ram usage peaked at 185mb.
with LO 6.1.2 on my win 10 notebook i can confirm: - ram usage goes up to 500 mb - hard recalc takes a long time (several minutes) - with Tools/Options.../LibreOfffice Calc/Formula "Always recalculate" loading takes a long time too
to be more precise: selecting [Enable Content] from "Automatic update of external links has been disabled" bar will increase memory usage (lo 6.2 ~ 330 mb, lo 6.1.2 ~ 500mb)
Calculation time it's because in sheet 'Actual' you have the whole columns of external file to do a conditional sum. Reducing the end of range, reduce drastically the time calculation.
(In reply to m.a.riosv from comment #6) > Calculation time it's because in sheet 'Actual' you have the whole columns > of external file to do a conditional sum. Reducing the end of range, reduce > drastically the time calculation. The point of raising this issue is the weird memory consumption of LO in a spreadsheet with quite number of linkages and formulas. My take on this is that if a LO spreadsheet will consume 300MB of memory, until the file is closed or saved, it will retain the 300MB. However in the current setup, after 10 - 15 mins of opening the file, the memory consumption went down and even if we hard recalculate all formulas, consumption is still lower compared to the first 10/15 minutes.
There are a lot of linked files, that need to be opened and I think it's not only LibreOffice, but also an OS matter, how they are released from memory. Test reopening the file after break all link Menu/Edit/Links
(In reply to m.a.riosv from comment #8) > There are a lot of linked files, that need to be opened and I think it's not > only LibreOffice, but also an OS matter, how they are released from memory. > > Test reopening the file after break all link Menu/Edit/Links Does this mean that this behavior is beyond "repair"? And on the instruction to test reopening after breaking all links, NO! The very purpose of raising this issue is to identify/solve the weird memory consumption on a spreadsheet with multiple linkages. Your instruction is not helping in solving the "possible" problem in the memory handling of LO. Breaking all the external links means that as if I am working only with a single spreadsheet file.
Dear perie_gut, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
> - ram usage goes up to 500 mb still reproducible with: Version: 6.3.2.2 (x64) Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: but i think the root cause for memory consumption and "freeze" are the 14 linked files.
This is marked as a regression by the original reporter, but comments 3 and 4 are in conflict. Is the last good version known?
As discussed in the earlier comments, there is a good reason for the higher mem use in the beginning. Also asked in the dev chat just now. Closing as notabug.
We should never consider reports like "I monitor memory consumption, and in new version it's higher than on an older version" (or "it peaks then lowers after while"). When looking at memory-related problems, the only ones that should be considered are those that result in crashes, or at least steadily growing memory consumption without releasing (leading to out-of-memory condition, indicating possible memory leak). Change in memory usage pattern like described here *might* be e.g. because of changed caching (used at load time, and released after a timeout) - say, loading images, then off-loading them, which would not require to reload them on recalc; or many other things. And of course, it is best to be consistent. The version shown in the bug "Version" field is 6.1.1.2, so it seems that that version was "problematic"; then comment 3 tells that 6.1.3 does not have the problem - "fixed"?; then comment 4 tells that 6.1.2 had this "problem" - so the "fix" was between 6.1.2 and 6.1.3 - but 6.2 is "better" than 6.1.2?; then comment 11 confirms *something* in 6.3.2.2...