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
Created attachment 129896 [details] Example file
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
low & minor ;)
That doesn't sound very minor if you're using an ssd drive and using up all your write cycles.
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
(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
(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.
Adding CC to: Michael Stahl
Probably the same issue as bug 78067, based the Xcode Instruments File Activity call tree
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