Bug 104882 - Lots of tmp file read/writes while scrolling a document containing PNG compared to LibO4.2
Summary: Lots of tmp file read/writes while scrolling a document containing PNG compar...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All Windows (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Image-Caching Too-Much-File-Access
  Show dependency treegraph
 
Reported: 2016-12-23 13:27 UTC by Telesto
Modified: 2017-11-23 21:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (392.06 KB, application/vnd.oasis.opendocument.text)
2016-12-23 13:28 UTC, Telesto
Details
Bibisect log (4.29 KB, text/plain)
2017-11-05 12:05 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2016-12-23 13:27:33 UTC
Description:
The disk access when scrolling through a document containing PNG has intensified heavily since the LibO4.2 series.

1. Lib4.2 doesn't have any disk activity at all (dconcerning tmp files)
2. Lib4.3 does have loads of reads when scrolling the file for the first time to the bottom. After the initial loading scrolling will normalize. However, when the document is inactive (idle), it will reset (after a tmp file read/save) (even with Autosave disabled) resetting the behavior (heavily disk access at 'first' scrolling, but it will normalize again.
3. LibO5 always keeps reading/writing to tmp files while scrolling down and up again. And feels sluggish.


Steps to Reproduce:
1.Open attached file
2.Monitor disk usage soffice.bin with Sysinternals Process Monitor and/or Process Explorer
3.Scroll the document up and down


Actual Results:  
Lots of disk activity

Expected Results:
Nearly no disk activity, similar to LibO4.2


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in:
Version: 5.4.0.0.alpha0+
Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02
Locale: nl-NL (nl_NL); Calc: CL

and in:
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL

and in
Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0

but not in
Versie: 4.2.0.4 
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Telesto 2016-12-23 13:28:09 UTC
Created attachment 129896 [details]
Example file
Comment 2 Buovjaga 2016-12-31 17:57:34 UTC
Yep, megabyte after megabyte being written when viewed in Process Explorer.

Win 10
Version: 5.4.0.0.alpha0+
Build ID: 7ed40deee74a9869b7da073ad473241187420ff8
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-30_23:18:54
Locale: fi-FI (fi_FI); Calc: group
Comment 3 Cor Nouws 2017-01-24 20:07:38 UTC
low & minor ;)
Comment 4 David 2017-06-16 23:15:20 UTC
That doesn't sound very minor if you're using an ssd drive and using up all your write cycles.
Comment 5 Telesto 2017-11-05 12:05:49 UTC
Created attachment 137537 [details]
Bibisect log

Bisected to:
commit 9b9eb2e4f619c63eabdc54b5d749ac55d8eaf333
Author:     Michael Stahl <mstahl@redhat.com>
AuthorDate: Fri Jan 31 23:00:24 2014 +0100
Commit:     Michael Stahl <mstahl@redhat.com>
CommitDate: Mon Feb 3 12:34:06 2014 +0100
    
fdo#73300: sw: don't swap in all images when loading files
Comment 6 Cor Nouws 2017-11-05 21:48:14 UTC
(In reply to Telesto from comment #5)

> fdo#73300: sw: don't swap in all images when loading files

So that reads as: read write activity is moved from loading to scrolling (actually looking into) the document
Comment 7 Telesto 2017-11-06 08:11:23 UTC
(In reply to Cor Nouws from comment #6)
> (In reply to Telesto from comment #5)
> 
> > fdo#73300: sw: don't swap in all images when loading files
> 
> So that reads as: read write activity is moved from loading to scrolling
> (actually looking into) the document

Yes. In my interpretation - so speculation: LibO was generation thumbnails (or something similar) of (at least) all png's when opening the file and swap them into the  document (so slow file opening).
Now the thumbnail creating has moved to 'scroll over'. The only problem: the thumbnail will be (re)created every time when 'scrolling over' instead of only once.
Comment 8 Telesto 2017-11-19 16:25:24 UTC
Adding CC to: Michael Stahl
Comment 9 Telesto 2017-11-19 18:15:21 UTC
Probably the same issue as bug 78067, based the Xcode Instruments File Activity call tree
Comment 10 Michael Stahl (CIB) 2017-11-23 21:03:49 UTC
This is intentional, we don't want to keep all images in RAM because that doesn't  work if there are too many images, see bug 73300