Bug 133644 - Memory usage after file save increases from 77MB in LibO 4.3 to 255MB in 7.1
Summary: Memory usage after file save increases from 77MB in LibO 4.3 to 255MB in 7.1
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2020-06-03 18:24 UTC by Telesto
Modified: 2020-06-23 13:01 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (3.50 KB, text/plain)
2020-06-03 18:25 UTC, Telesto
Details
Bibisect log (3.37 KB, text/plain)
2020-06-03 18:27 UTC, Telesto
Details
Bibisect log 5.3 (4.65 KB, text/plain)
2020-06-03 18:28 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-03 18:24:07 UTC
Description:
Memory usage after file save increases from 77MB in LibO 4.3 to 255MB in 7.1

Steps to Reproduce:
1. Open attachment 160498 [details] and take notice of the memory usage of soffice.bin
2. Save the file and take notice off the memory usage of soffice.bin
3. Close the document and take notice off the memory usage of soffice.bin

Actual Results:
4.4 oldest
Open 65
After save 77
Close 76

4.4 origin/master
Open 71
After save 194
Close 100

5.2 oldest
Open 75
After save 110
Close 93

5.2 origin/master
Open 75
After save 153
Close 101

5.3 origin/master
Open 84 MB
After save  211 MB
Close 112

6.1 origin/master
Open 95 MB
Save 217 MB
Close 119

6.2 origin/master
On open 153
After save save 255
On close 150 MB

Expected Results:
Somewhat around 4.4 oldest would be nice..  but 100 MB is also fine :-)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 83c4f86f22dc37269ac6a038fe7de053c42aad6e
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-06-03 18:25:53 UTC
Created attachment 161587 [details]
Bibisect log

Memory bump 4.3 - 4.4, bisected to:
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sun Mar 15 05:15:23 2015 +0800

    source-hash-b2503f187341f9a37737f34c7fc6a02d03c2e84e
    
    commit b2503f187341f9a37737f34c7fc6a02d03c2e84e
    Author:     Zolnai Tamás <tamas.zolnai@collabora.com>
    AuthorDate: Sat Oct 18 15:06:57 2014 +0200
    Commit:     Zolnai Tamás <tamas.zolnai@collabora.com>
    CommitDate: Fri Nov 7 10:45:07 2014 +0100
    
        Remove manual SwapOut() call in ODF export
    
        We have a good auto swapout mechanism which will
        prevent excessive memory use.
    
        Change-Id: I362f51c724ac31704561abe8b961910f5d490f04
Comment 2 Telesto 2020-06-03 18:27:04 UTC
Created attachment 161588 [details]
Bibisect log

Bump between 5.1 - 5.2 bisected to
author	Akshay Deep <akshaydeepiitr@gmail.com>	2016-03-07 08:45:54 +0400
committer	Michael Meeks <michael.meeks@collabora.com>	2016-03-23 17:29:08 +0000
commit 75c272c146045235783e1dfe26a162a8f4dee493 (patch)
tree afdde04a304e149c297c57e7fff18b5dbaa8585d
parent b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 (diff)
tdf#94760 Better default values for graphics cache
Changed Total Graphic Cache Size to 64 Mb.
Changed Object Cache Size to 12 Mb.
Comment 3 Telesto 2020-06-03 18:28:12 UTC
Created attachment 161589 [details]
Bibisect log 5.3

Bump between 5.2 and 5.3 bisected to:
author	Michael Stahl <mstahl@redhat.com>	2016-11-09 12:44:43 +0100
committer	Michael Stahl <mstahl@redhat.com>	2016-11-09 13:05:44 +0100
commit 41de4df1cfbe02fcd235582b50c87c9d91757809 (patch)
tree 1e61d5a47342d12e376a188e44bf588c5855f3a2
parent ed42212f53b2e52238346e64dae31a931d6c90a1 (diff)
increase Office::Common::Cache::GraphicManager::TotalCacheSize to 200MB
We can use a bit more RAM for graphics than we currently do, even on 32
bits, which should improve interactive performance as there will be less
swapping of bitmap data and re-parsing of SVGs.

Note that currently the value is effectively multiplied by 2, as the
limit is stored in GraphicCache::mnMaxDisplaySize, but there are 2
independent "counters" GraphicCache::mnUsedDisplaySize and
GraphicManager::mnUsedSize that are both checked against the same limit.
Comment 4 Telesto 2020-06-03 18:35:22 UTC
The bump between 6.1 and 6.2 is not image related.. reported under bug 133645
Comment 5 Buovjaga 2020-06-18 15:57:17 UTC
Again explained by use of cache, nothing wrong with that
Comment 6 Telesto 2020-06-23 13:01:11 UTC
(In reply to Telesto from comment #1)
> Created attachment 161587 [details]
> Bibisect log
> 
> Memory bump 4.3 - 4.4, bisected to:
> Author: Matthew Francis <mjay.francis@gmail.com>
> Date:   Sun Mar 15 05:15:23 2015 +0800
> 
>     source-hash-b2503f187341f9a37737f34c7fc6a02d03c2e84e
>     
>     commit b2503f187341f9a37737f34c7fc6a02d03c2e84e
>     Author:     Zolnai Tamás <tamas.zolnai@collabora.com>
>     AuthorDate: Sat Oct 18 15:06:57 2014 +0200
>     Commit:     Zolnai Tamás <tamas.zolnai@collabora.com>
>     CommitDate: Fri Nov 7 10:45:07 2014 +0100
>     
>         Remove manual SwapOut() call in ODF export
>     
>         We have a good auto swapout mechanism which will
>         prevent excessive memory use.
>     
>         Change-Id: I362f51c724ac31704561abe8b961910f5d490f04

Image cache..