Bug 120498 - FILEOPEN: Libreoffice uses 1.000 MB of memory from 6.1 to open 24 MB DOC with images (per Comment 5), MSO peaks 150 MB
Summary: FILEOPEN: Libreoffice uses 1.000 MB of memory from 6.1 to open 24 MB DOC with...
Status: RESOLVED DUPLICATE of bug 124828
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, perf
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2018-10-11 03:03 UTC by 張修銘
Modified: 2019-04-24 09:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
doc file I created to reproduce the bug (22.69 MB, application/msword)
2018-11-15 15:01 UTC, 張修銘
Details
docx file for comparison (22.49 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-11-15 15:02 UTC, 張修銘
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 張修銘 2018-10-11 03:03:23 UTC
Description:
When I try to open a pptx file my teacher gave me, Libreoffice Impress uses lots of memory (about 2.2 GiB). Sorry I can not upload the file now, I will see how I can remove copyrighted parts. I have bibisect the bug.

Steps to Reproduce:
1.Open the file

Actual Results:
Libreoffice uses 2.2 GiB memory

Expected Results:
Libreoffice uses less memory (in Libreoffice 6.0.6, it uses less than 400Mib memory)


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.1.2.1
Build ID: 6.1.2-1
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: zh-TW (zh_TW.UTF-8); Calc: group threaded
Comment 1 張修銘 2018-10-11 03:05:28 UTC
bibisect result: 72bc80efafdf7748e54c5ec55b278b3cb870ab57 is the first bad commit
commit 72bc80efafdf7748e54c5ec55b278b3cb870ab57
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Apr 20 21:32:22 2018 +0200

    source b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e
    
    source b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e

:040000 040000 33fa0b071cf3b09541e3e806afe3a846574d26cc a040feb363e69289c8fb04363f7151220e386cf2 M	instdir

log:
# bad: [7be3595695f015636e6d2be8b6b3d72209bad419] source feb475c6594c5520ea50ba74e8c17e8a1815dc1f
# good: [2c1cccc19f9e70d2ecbc9ba7815abd674ab6d858] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9
git bisect start 'origin/master' 'oldest'
# good: [59612f2aa9f39643f3ef5c4f17028c84e1938103] source f5850c7841e98c9f91076ea0e0b840374766bfca
git bisect good 59612f2aa9f39643f3ef5c4f17028c84e1938103
# bad: [f5188869b635b45b172a13acb03759f6bfe702a5] source 09de927ba60db4ab5c55aae15a0b0d049b298a4c
git bisect bad f5188869b635b45b172a13acb03759f6bfe702a5
# good: [287c08658a07917df0a79a935063ce1f453f7000] source 0dde5e7d6c69fbf59a898b019ef230adfef30633
git bisect good 287c08658a07917df0a79a935063ce1f453f7000
# good: [85b83130959a2ee823216dad76aa76568da7a570] source d43fa87fbcb46a44e61338105b6da9eb8a1a5b15
git bisect good 85b83130959a2ee823216dad76aa76568da7a570
# good: [bb3e560b696480b92659b50ef5fa427a8ab17402] source 77bfe10480bc77fe29d989785c8fda4cb3946560
git bisect good bb3e560b696480b92659b50ef5fa427a8ab17402
# bad: [d3b9d3218ff0e1498a3f46d19500674798e6f402] source a3895160f7981099a800de2458a0a946d60cac17
git bisect bad d3b9d3218ff0e1498a3f46d19500674798e6f402
# good: [d6e6eee353fdbae26e66563376a3c47c4735b881] source 73584b2342b4e527b5329b4bf779171c4fc2d4ce
git bisect good d6e6eee353fdbae26e66563376a3c47c4735b881
# bad: [2bd6b88efcbdc7bbaea1ec5c69a076592a1bf30a] source eb5c0ccd47330fc726f4b4f854cf4cc518ac21cd
git bisect bad 2bd6b88efcbdc7bbaea1ec5c69a076592a1bf30a
# good: [aca85a3004cfbec3e653c6e4acb8afe6fc79b667] source 56775815a39c2ee4a0f711738947d2fb234c4923
git bisect good aca85a3004cfbec3e653c6e4acb8afe6fc79b667
# good: [c8b8cad943bbf11bc54809af13823a2f1e39c6ca] source 0be3db28a4db4d2c81a5cb2edd48711eec55b51b
git bisect good c8b8cad943bbf11bc54809af13823a2f1e39c6ca
# good: [8a375cda52fc9b0cccc753d1f7ee2344f3501e3e] source edda1e5fc8113aa4744e32f97c96a3cc311485ca
git bisect good 8a375cda52fc9b0cccc753d1f7ee2344f3501e3e
# bad: [72bc80efafdf7748e54c5ec55b278b3cb870ab57] source b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e
git bisect bad 72bc80efafdf7748e54c5ec55b278b3cb870ab57
# good: [2cd35381cccc07be053ee7b1b45d0c0babb9f057] source 40edbce3988946d0ffceb9554de42e1e469edd92
git bisect good 2cd35381cccc07be053ee7b1b45d0c0babb9f057
# first bad commit: [72bc80efafdf7748e54c5ec55b278b3cb870ab57] source b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e
Comment 2 張修銘 2018-10-11 04:31:45 UTC
Sorry, it is a ppt file. I tried removing copyrighted parts, but I can not reproduce the bug with those parts removed.
Comment 3 Telesto 2018-10-11 06:49:11 UTC
https://cgit.freedesktop.org/libreoffice/core/commit/?id=b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e

author	Miklos Vajna <vmiklos@collabora.co.uk>	2018-04-20 17:58:09 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2018-04-20 21:12:56 +0200
commit b11188835d3b87cd9d2a8cdb3da204cfda5d3e6e (patch)
tree d4c652363b1f20e7399be1fd01d74099e3aa8f3c
parent 40edbce3988946d0ffceb9554de42e1e469edd92 (diff)
DOC import: lazy-read images
At least JPEG files are now only loaded when the user scrolls to the
relevant page.

Also fix the root cause of the EMF lazy-read problem and remove the
previous workarounds.
Comment 4 張修銘 2018-10-22 02:27:46 UTC
Hello. I created a ppt file with lots of pictures, and I can reproduce the bug. I also have an interesting finding. If I save the file as pptx, I can't reproduce this bug. The following is the memory usage of ppt and pptx, open with Libreoffice 6.1.2 and 6.0.6.

6.1.2.1 ppt: 1.5 GiB
6.1.2.1 pptx: 639 MiB
6.0.6.2 ppt: 569 MiB
6.0.6.2 pptx: 656 MiB

Because the files are big, I use a link to Google Drive instead of attachment. Here is the link: https://drive.google.com/drive/folders/1ePMks0we8aFAjtmB1Py49fX33fLV1sAH?usp=sharing
Comment 5 張修銘 2018-11-15 14:58:49 UTC
Seems that this bug also affects LibreOffice Writer. I created a doc file with lots of images and open in LibreOffice Writer. LibreOffice 6.1 uses lots of memory, but LibreOffice 6.0 does not (I test with Appimage). Here is the comparison:

6.1.3.2 doc: 1021 MiB
6.1.3.2 docx: 248 MiB
6.0.7.3 doc: 510 MiB
6.0.7.3 docx: 513 MiB

Additional Info:
Version: 6.1.3.2
Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: zh-TW (zh_TW.UTF-8); Calc: group threaded
Comment 6 張修銘 2018-11-15 15:01:02 UTC
Created attachment 146667 [details]
doc file I created to reproduce the bug
Comment 7 張修銘 2018-11-15 15:02:10 UTC
Created attachment 146668 [details]
docx file for comparison
Comment 8 JustinEl 2018-11-29 08:39:50 UTC
Bug confirmed.
It takes about 1G of memory in my case,while microsoft word only need 100MB of memory.

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded
Comment 9 Xisco Faulí 2019-04-24 09:57:00 UTC
This should be fixed by https://git.libreoffice.org/core/+/af84fc9d906626255aaf136eefc5e55236e0e8a6%5E%21
Closing as duplicate of bug 124828

*** This bug has been marked as a duplicate of bug 124828 ***