Description: Extreme memory usage opening/saving a large ODS with tracking changed enabled Steps to Reproduce: 1. Open the attached file (notice mem usage on file open) 2. Save the file (monitor mem usage) 2. Compare with attachment 150858 [details] Actual Results: 375 MB for attachment 150858 [details] 1,4 GB for the attached file Expected Results: Overhead is fine.. but seems bit of scale Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.0.0.alpha0+ (x64) Build ID: 95462a02a3aee1e3e7f9aa8fc50ba25fee3fa592 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-03_07:09:38 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 151911 [details] Example file
well, it seems there are hundreds of comments in the document. This is already reported in bug 76324 *** This bug has been marked as a duplicate of bug 76324 ***
@Telesto: nice stresstest, nice apt comment, thumb up, @all: to pinpoint a bug it's good practice to reduce size, impact and complexity to a minimum, to prove overall correctness it's neccessary to boost size, impact and complexity to a maximum, @Xisco: imho you're wrong, this bug is not about 'comments' (red dot in upper right corner of cell), but about 'change notes' (red dot in upper left corner of cell), thus resetting to new, additional observation: on my system calc stopped showing the yellow change notes somewhere around row 69.000, physical ressources where available (8.9 GB free mem), are there internal resource limitations? @all: from the analysis made in #76324 and the behaviour shown for this bug it's very likely that they have the same root - drawing of boxes, a hidden drawing layer for copies to clipboard, sort operations instead of lookups, shallow copies not 'when needed' but 'in preparation' for each and every element on each and every action, e.g. also on mousemoves not even leaving the cell, ineffective definition for 'additional info' in the file standard? and similar annoyances will, of course, affect this sheet as well as sheets with lots of comments ... but ... they are connected, related, correlated, whatever, it's not! the same bug - until someone kills it and both symptoms disappear. imho it's not! a good practice to 'kill' each and every new report - which contributes to the knowledge about weaknesses - as 'duplicate' of old bugs where most users and programmers say 'old stuff' we have lived with that for years, that can go on ... while others who take a deeper look say: 'That's a monster, it's better to keep Pandora's box closed'. we? (you?) do! have some of these monsters in the code (imho (assumption, sorry Eike) buried under hundreds of 'patches' and tons of plaster that cover up some of their symptoms) ... after five and more years - imho - it's overdue to develop a strategy to get rid of them. monsters i've seen: shared formulae break autocalculate, buggy implementation of shared formulas? ineffective handling of comments and similar stuff, big performance impact once using to much of it, reg. b.
i just tried 6.4 for a short time, at first glance ... massive improvements in all areas ... respect!, i already lost hope, not necessarily finished, but - at first sight - 'usable', thank you very much, Version: 6.4.0.0.alpha0+ (x64) Build ID: 758516295e5f69393bd78bb4af6e7214d48ece0b CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: Linux similar ver. with 'alpha1', or might it result from 'Calc: ' opposite to 'Calc: CL', i don't know the meaning of 'CL', thank you very much, b.
Dear Telesto, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug