Description: Memory usage increases after file open/file close but not in 4.2 Steps to Reproduce: 1. Download the attached file & extract to a folder 2. Open LibreOffice / Start Center 3. File open -> Select all files at once 4. Wait until finished.. and monitor memory usage 5. Close all the documents (back to start center) & monitor memory usage Actual Results: With build after the commit All documents open: 440 After closing all documents: 198 Expected Results: All documents open: 317 After closing all documents: 132 Reproducible: Always User Profile Reset: No Additional Info: -
Created attachment 161400 [details] Bibisect log Bibisected to the following range on MacOS https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=afd16e30f679e8e1e86edf1ee4185cf5b9cf4186...52999789258aa7cfde8d01ff7e8a03a0f53278d Expected cullprit author Michael Meeks <michael.meeks@collabora.com> 2013-11-22 18:06:44 +0000 committer Michael Meeks <michael.meeks@collabora.com> 2013-11-22 18:07:40 +0000 commit 945d5a010b9cd2f9ab9b804a3cc51c7b46844c3b (patch) tree 8696217aaddb7179b9b1cd8f81dfc2e42e9c06cb parent 35f0a01b5e320ef3a5f0c82e24ecf889d8f9d455 (diff) oox: avoid per element allocation and freeing of OUStringBuffers. https://cgit.freedesktop.org/libreoffice/core/commit/?id=945d5a010b9cd2f9ab9b804a3cc51c7b46844c3b
Created attachment 161402 [details] Example files used
Again, rule of thumb: "Is it catastrophic?" - no, so let's close.
(In reply to Buovjaga from comment #3) > Again, rule of thumb: "Is it catastrophic?" - no, so let's close. To be or not to be. A bug is only a bug if "catastrophic"? So we can ignore crashes.. mostly not ending catastrophic :-). Is it catastrophic if LibreOffice would disappear as Openoffice did? Would human kind not survive? Or is the world being blown apart by some asteroid, erasing humankind a catastrophic? Is there catastrophe without any human surviving it? Was it a catastrophic for the dinosaur to extincts.. did the have a problem with it.. What did they do to prevent it? Why did the fail? So 'catastrophic' no.. a bug yes, trivial likely.. however not able to asses the scope .. this type of issue tends to cause problems if LibreOffice process is kept alive long time.. opening and closing documents.. So now extent the scope.. Do 500 runs opening/ saving/ closing a document.. what would the result be? I was able to bibisect it.. so it is at minimum not a sporadic something.. And I personally found it an issue.. I have noticed it, bibisected, bisected it.. even if it's a crazy thing to do. So there is a flaw.. big.. as said.. depends on user case... If it can be prevented.. functioned better.. why not take notice.. Or there should be something in system requirements.. about LibreOffice is designed for usages 5 hours a day, using maximum 30 documents of a size of 5 MB. Afterwards LibreOffice needs to closed and restarted.. image can only inserted with resolution of 4 megapixels; and only 50 images are allowed.. [all the limitation can be build in] Also at the one end.. people are working on making LibreOffice work on tables/phones (image handling).. See https://bugs.documentfoundation.org/show_bug.cgi?id=130768 on the other hand we are doing as if memory can be used freely.. bug 130768 is a waste of effort.. you can also say.. why should LibreOffice adapt.. blame the phone maker.. with those silly specs.. and blame users should ask for phones which a capable to run LibreOffice.. Another perspective: wait until a phone gets released which can run LibreOffice.. So is this a HIGHEST/CRITICAL bug no of course not.. should this be tracked.. ideally yes.. As vector for memory optimizations.. Is somebody gonna do that.. No clue.. Hopes, hopes, hopes.. But closing as not a bug.. feels like ignoring it.. or sweeping it under the carpet; of course different story if nobody can reproduce it .. Or the whole discussion of what should be what worthy of 'bug' label. Similar to the going backwards, and something being a regression (or even a bug?). But if going backwards bugs, feels bug and can't be an improvement. How should be called .. [i'm open for suggestions]. And is there a tracker for other stuff, which can't be listed in the bug tracker because it misfits..
(In reply to Telesto from comment #4) > (In reply to Buovjaga from comment #3) > > Again, rule of thumb: "Is it catastrophic?" - no, so let's close. > > To be or not to be. A bug is only a bug if "catastrophic"? So we can ignore > crashes.. mostly not ending catastrophic :-). Is it catastrophic if > LibreOffice would disappear as Openoffice did? Would human kind not survive? > Or is the world being blown apart by some asteroid, erasing humankind a > catastrophic? Is there catastrophe without any human surviving it? Was it a > catastrophic for the dinosaur to extincts.. did the have a problem with it.. > What did they do to prevent it? Why did the fail? Crashing is exactly the sort of catastrophic outcome I was referring to. The point was: if you are not dealing with a catastrophic out-of-memory situation and you do not understand, why a decision was made regarding resource use, there is no need to report it. The reports I closed yesterday were clearly about using a cache or an allocator. The results would have been alarming, if we were talking about a sudden increase of 2GB used mem per operation. > Also at the one end.. people are working on making LibreOffice work on > tables/phones (image handling).. See > https://bugs.documentfoundation.org/show_bug.cgi?id=130768 > on the other hand we are doing as if memory can be used freely.. bug 130768 > is a waste of effort.. you can also say.. why should LibreOffice adapt.. > blame the phone maker.. with those silly specs.. and blame users should ask > for phones which a capable to run LibreOffice.. Another perspective: wait > until a phone gets released which can run LibreOffice.. Again, like I mentioned in another report, being able to achieve stuff in memory is BETTER for tablets and phones, because it uses way less POWER and thus gives better battery life. The commits from the reports I closed yesterday were about improving performance by taking advantage of memory. There is nothing wrong with tweaking resource use (CPU vs. mem) to achieve a desired outcome. Quoting Miklos from bug 133667: "if somebody is interested, we could look at if it's possible to use less memory while maintaining the same performance, I didn't investigate this direction so far." So the question is essentially: is perfect the enemy of the good? At some point, you have to stop solving a problem. There is no point in turning every single task into a PhD dissertation. New innovations may arrive and bring unexpected improvements, but there is no value in creating reports in the hope that some future advance in computer science will bring some marginal benefit.