Bug 158539 - Memory usage increases with steps of +/-100 MB on each save and reload after simply image modification (macOS)
Summary: Memory usage increases with steps of +/-100 MB on each save and reload after ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha1+
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-05 11:39 UTC by Telesto
Modified: 2024-06-29 02:35 UTC (History)
0 users

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2023-12-05 11:39:16 UTC 
Description:
Memory usage increases with steps of +/-100 MB on each save and reload after simply image modification

Steps to Reproduce:
Steps are more or less the same as bug 158536
1. Open attachment 173542 [details]
2. Select the camera image and press F4 (Image Properties dialog)
3. Go to position and size tab
4. Check 'Keep Ratio' 
5. Reduce the image width by pressing 1x decrease on the spinbutton (9,90 cm)
6. Press OK
7. Press Save
8. Press File -> Reload
9. Repeat 3-9 multiple times (say 5x). +/- 1,5 GB ram needed

Observed with Skia/Raster as with Skia/Vulkan and OSX rendering. 

Note: there is also some increase on save and reload without modification, but only 5-10 MB.

Actual Results:
1,5 GB ram

Expected Results:
500-700 MB


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 1a74a87b442857567d20da5dc97bbbc278745afd
CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded
Comment 1 Raúl Osuna 2023-12-29 10:05:04 UTC 
Probably not very useful in a different OS, but I tried around 10 times (till 9,00cm) and didn't see much of a change:

Before:
raul@mordor:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi       8,6Gi        44Gi       263Mi        10Gi        53Gi
Swap:          2,0Gi          0B       2,0Gi

After:
raul@mordor:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi       8,5Gi        44Gi       267Mi        10Gi        53Gi
Swap:          2,0Gi          0B       2,0Gi

Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 16; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb)
Locale: es-ES (es_ES.UTF-8); UI: es-ES
Calc: threaded
Comment 2 Raúl Osuna 2023-12-29 10:08:25 UTC 
Also tried again, from 9,00cm to 8,00cm, but this time showing values in MB, as the GB could be misleading:

Before:
raul@mordor:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           64007        8778       45860         276       10304       55229
Swap:           2048           0        2048

After:
raul@mordor:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           64007        8755       45882         276       10305       55252
Swap:           2048           0        2048

I would say not happening in GNU/Linux (openSUSE Tumbleweed).
Comment 3 Telesto 2024-06-29 02:35:38 UTC 
Appears to be fine
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 9c1a48f844eaefc505a5914338b6f444011bf315
CPU threads: 8; OS: macOS 14.3; UI render: default; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded