Bug 124419 - Memory usage for 4 documents containing a table of 10 columns 1500 cells
Summary: Memory usage for 4 documents containing a table of 10 columns 1500 cells
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2019-03-29 09:57 UTC by Telesto
Modified: 2023-04-26 03:23 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect (2.44 KB, text/plain)
2019-04-24 13:17 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-03-29 09:57:43 UTC
Description:
Memory usage for 4 documents containing a table of 10 columns 1500 cells doubled

Steps to Reproduce:
1. Open Writer
2. CTRL+F12
3. Column 10: cells 1500 
4. CTRL+N + step 2/3 (until 4 documents open)

Actual Results:
LibO6.3 295 MB on 32x with automatic spell checker enabled; without 255
Libo4.4.7.2: +/-150 mb

Expected Results:
Something like 4.4.7.2


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.3.0.0.alpha0+
Build ID: 20ea90a557b5bc744fd234e3a20ab1db484cf88b
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-03-22_03:21:58
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded
Comment 1 mulla.tasanim 2019-04-03 20:17:06 UTC
Thank you for reporting the bug.


I have observed following memory usage with automatic spell checker enabled
Version: 6.3.0.0.alpha0+: 120.2MB
Version: 6.2.1.2:

I can not reproduce the bug in

Version: 6.2.1.2 (x64)
Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL


Version: 6.3.0.0.alpha0+ (x64)
Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 2 mulla.tasanim 2019-04-03 20:18:46 UTC
In Version 6.2.1.2:    134.7MB
Comment 3 Buovjaga 2019-04-23 18:44:22 UTC
I repro - in 6.3 I see over 200 MB while in 5.0 it is 80 MB.

There is a bump from 120 MB to 190 MB in the last commit of win32-bibisect-6.0 and the first commit of win32-bibisect-6.1, so I am unable to bibisect.

Telesto: can you try the bibisect repos?

Also seen on Linux.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: b8f33d053c2cbf05872cf9ddfeff4cc302ee281f
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 20 April 2019
Comment 4 Telesto 2019-04-24 13:17:04 UTC Comment hidden (obsolete)
Comment 5 Telesto 2019-04-24 13:25:07 UTC
Note: comment 0 is bit of distracting.. table stuff doesn't really matter.. can be seen without too (however the need to be some user interaction to fully load everything . Clicking Tools menu or typing something).. At least for 5.3 branch (see bug 104332)
Comment 6 Buovjaga 2019-04-24 13:34:56 UTC Comment hidden (obsolete)
Comment 7 Telesto 2019-04-24 16:27:41 UTC
(In reply to Buovjaga from comment #6)
> (In reply to Telesto from comment #4)
> > Memory usage is in normal range in newer version when disabling OpenCL (or
> > using with OpenCL prior to the given commit )
> 
> Then how come I could repro even though I did not have OpenCL enabled?
Valid point

> It sounds weird that a Calc thing would affect Writer.
Maybe, maybe not.. the OpenCL check happens on initialization of LibO.. so maybe not properly disposed or something like that .. 

Bibisected this type of issue is like hell IMHO. Never certain what you are comparing between versions. Compiler stuff. Memory bug A got fixed in exchange for bug B :-). Dictionary's.. So hard to tell what to expect

Bug 104332 increased mem usage when launching.. IMHO
Layout caching did increase mem usage also 

Anyway probably stacking multiple issue around here, lovely (or my drivers are broken somehow)

Results with Version: 6.1.0.0.beta2+ 
Build ID: 033400a7524813b4eccf8f90a7647bc0121e75dd

169 MB without OpenCL & OpenGL
219 MB with OpenCL enabled & without OpenGL
370 MB with OpenGL without OpenCL

Results with Version: 6.3.0.0.alpha0+
Build ID: 3083fe569f96bf0289da1e9d0ef7da15ab22e2f6
230 without OpenCL & OpenGL
294 with OpenCL & without OpenGL enabled
404 with OpenGL without OpenCL
Comment 8 Telesto 2019-04-24 19:46:56 UTC
Main root issue probably older.. 190 MB without OpenCL and OpenGL with
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 9 Buovjaga 2019-04-24 20:57:45 UTC
(In reply to Telesto from comment #8)
> Main root issue probably older.. 190 MB without OpenCL and OpenGL with
> LibreOffice 3.5.7.2 
> Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b

But this sounds like the usage has changed like a rollercoaster since 3.5, high, low and now again high.
Comment 10 Telesto 2019-04-25 06:24:56 UTC
(In reply to Buovjaga from comment #9)
> (In reply to Telesto from comment #8)
> > Main root issue probably older.. 190 MB without OpenCL and OpenGL with
> > LibreOffice 3.5.7.2 
> > Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
> 
> But this sounds like the usage has changed like a rollercoaster since 3.5,
> high, low and now again high.

I would say so.. but there are so many variables.. obvious ones OpenCL, OpenGL, Spell Checker and the glitch observed in comment 3 (which i have seen a few times; and doesn't make much sense either)  

Still think that there is something off somewhere..but I give up for now
Comment 11 QA Administrators 2021-04-25 04:02:35 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2023-04-26 03:23:33 UTC
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