Bug 128280 - Memory usage doesn't drop to initial state after closing document in print preview mode
Summary: Memory usage doesn't drop to initial state after closing document in print pr...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2019-10-20 19:07 UTC by Telesto
Modified: 2024-02-06 18:51 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-10-20 19:07:07 UTC
Description:
Memory usage doesn't drop to initial state after closing document in print preview mode

Steps to Reproduce:
1. Open Writer
2. Open ProcesExplorer or other CPU/memory monitor
3. Check the baseline memory usage (210 MB x32)
4. Open the attachment 145863 [details]
5. Wait until loading is finished (CPU drops back).. memory usage 285 MB
6. Switch to print preview
7. Press and hold page down until to bottom is reached.. Memory usage will increase (389 MB)
8. Close the document (gray cross). Memory usage will be 244,8 (for start center)
9. Repeat 4-8 = 258.6 MB (for start center); 270 for new Writer document

Actual Results:
Memory usage increases slowly

Expected Results:
Memory usage shouldn't increase


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.0.0.alpha0+ (x86)
Build ID: c45d477b0a0038d9c25176cf7cff299e5ddf3a7a
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-09-30_05:06:55
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 1 Buovjaga 2020-04-26 14:51:07 UTC
Confirmed. Can you check if it behaved differently in an older version?

Arch Linux 64-bit
Version: 7.0.0.0.alpha0+
Build ID: 6a9c7409ee617b79c327dd7ea4de432f448b6006
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 24 April 2020
Comment 2 QA Administrators 2022-04-27 04:01:40 UTC Comment hidden (obsolete)
Comment 3 Tex2002ans 2024-02-06 10:45:27 UTC
Hmm... Unsure if this still *might* be a thing in:

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Yes, it was a little higher, but it looked like my RAM usage peaked out + even "stabilized" after a few repeats.

(Maybe LO only "holds"/caches a few lingering previous copies in memory?)

- - -

Looking at my memory usage:

356.0 MB = Step 1 (Fresh LO Writer)
519.4 MB = Step 5 (Fully loaded document)
513.9 MB = Step 7 (Print Preview + PageDown to end)
517.8 MB = Step 8 (Start Center)

(~160 MB higher)

Repeat 1:

520 MB = Step 4 (Load same ODT Document again)
685 MB = Step 8
--- (~160 MB higher)

Repeat 2:

579 MB = Step 4 (Load same ODT Document again)
672 MB = Step 8
--- (~100 MB higher)

Repeat 3:

676 MB = Step 4 (Load same ODT Document again)
685 MB = Step 8
--- (~10 MB higher, but Step 4 had a huge jump up from before.)

Repeat 4:

670 MB = Step 4 (Load same ODT Document again)
594 MB = Step 8
--- (~80 MB lower)

Then it continued around that same range the next few times:

- ~590-690 MB

Yes, 600-700ish MB was higher than a pure fresh LO launch (356 MB)... but it didn't seem to be growing and growing after that.
Comment 4 Telesto 2024-02-06 18:51:22 UTC
Seems fine indeed
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1
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 threaded