Bug 111338 - LibO will update the registrymodifications.xcu for every color chosen in the color picker (since LibO 5.3)
Summary: LibO will update the registrymodifications.xcu for every color chosen in the ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta2
Hardware: All Windows (All)
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: Color-Picker-Widget Too-Much-File-Access
  Show dependency treegraph
 
Reported: 2017-08-04 12:03 UTC by Telesto
Modified: 2020-10-28 16:43 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-08-04 12:03:02 UTC
Description:
When a color is chosen in the color picker, a tmp file is written (since LibO5.3)

Steps to Reproduce:
1. Open Writer
2. Type something on the first row (and select it)
3. Open Process Monitor.
4. Set a filter PATH contains Data\settings\user\
5. Open the font color picker an choose a font color. 

Actual Results:  
A small temp file is written. The temp file is created in various cases. See bug 108655. However this one is introduced recently and LibO5.2 is working perfectly fine without.

Expected Results:
The temp write is probably not needed. So no Write at all


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: 6.0.0.0.alpha0+
Build ID: 46b9d35ceaba80ce73fb0b4b5a87dbdf0a674628
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-08-02_23:46:51
Locale: nl-NL (nl_NL); Calc: CL

and in
Version: 5.3.0.0.beta2+
Build ID: f4b7650ecd46e5404b35dccfb8b7d3b0a385d633
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2016-12-16_12:19:09
Locale: nl-NL (nl_NL); Calc: CL

but not in:
Version: 5.2.5.0.0+
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 tommy27 2017-08-04 14:07:40 UTC
is this temp file subsequently deleted or overwritten?
Comment 2 Telesto 2017-08-04 14:43:42 UTC
(In reply to tommy27 from comment #1)
> is this temp file subsequently deleted or overwritten?

I can be a bit more specific after looking more closely at the output. The change in the color picker initializes a registrymodifications.xcu update. The change is written into a *.tmp file, renamed to registrymodifications.xcu after a successful save. The process takes up +/- 1 millisecond
Comment 3 Telesto 2017-08-04 15:02:37 UTC
To be more precise, the registrymodifications.xcu update is related to two settings: RecentColor and RecentColorName

<item oor:path="/org.openoffice.Office.Common/UserColors"><prop oor:name="RecentColor" oor:op="fuse"><value>0</value></prop></item>

<item oor:path="/org.openoffice.Office.Common/UserColors"><prop oor:name="RecentColorName" oor:op="fuse"><value><it>Black</it></value></prop></item>
Comment 4 Telesto 2017-09-08 18:28:29 UTC
About the expected results, because it has a purpose seen in the light of comment 3:

Probably a (changeable) interval based save. 
1. Re-saving registrymodifications.xcu on every change seems to be a bit excessive to me (especially because of the increasing file size when using different applications within the LibO suite). It will end op writing around 400kb every time when touching the highlight or color button (for example; there are more cases)
2. Being smart an hold of saving until LibO closes isn't that ideal either. For example when LibO is crashing or for debugging purposes.
Comment 5 Xisco Faulí 2018-11-26 19:10:10 UTC
Hi Telesto,
is this issue still reproducible in master ?
Comment 6 Telesto 2018-11-27 15:49:25 UTC
Still the same
Version: 6.3.0.0.alpha0+
Build ID: d71ea82055a6a304493c7eaa90809a348e23784d
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-19_03:25:07
Locale: en-US (nl_NL); UI-Language: en-US
Calc: CL
Comment 7 Xisco Faulí 2019-05-30 11:16:13 UTC
Hi Telesto,
any chance this could be bisected ?
Comment 8 Xisco Faulí 2019-07-05 10:17:58 UTC
(In reply to Xisco Faulí from comment #7)
> Hi Telesto,
> any chance this could be bisected ?

ping ?
Comment 9 Telesto 2019-07-05 12:31:28 UTC
Not sure if there is much to gain from it.. It's more a global design problem I guess.. The xcu is immediately updated on every change (floating dialogs, colors, window position etc). As such acceptable (but not ideal) if the xcu isn't to large. However this isn't the case. A xcu size of 2-4 MB isn't to exceptional causing a crazy amount of disk activity storing mostly trivial things

Lazy writing of xcu would be a solution. So storing a some intervals. Release build only of course as I might be problematic for debugging.
Another solution would be splitting settings to different xcu's but half-house solution; probably not desired anyway (backward compatibility ) 

It needs a Dev Evaluation IMHO
Comment 10 Xisco Faulí 2020-01-20 17:16:44 UTC
anyway, a bisection would be really helpful here
Comment 11 Telesto 2020-01-22 21:50:02 UTC
Bisected to:
author	Rishabh Kumar <kris.kr296@gmail.com>	2016-07-29 18:39:46 +0530
committer	Rishabh Kumar <kris.kr296@yahoo.in>	2016-07-29 14:52:56 +0000
commit 7f262a41017685709c288b57c8f03244e8c6149e (patch)
tree 130677ce67e64e47ab6341fa59a9ecac8fae2b63
parent bb01247f71a46fb7cae18b51516096adfd059bbc (diff)
[GSoC] Fix recent colors in color popup widget
Save recent colors in user configuration.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=7f262a41017685709c288b57c8f03244e8c6149e
Comment 12 sukamin 2020-06-06 08:10:47 UTC Comment hidden (spam)
Comment 13 Buovjaga 2020-10-19 11:46:25 UTC
I started thinking the current behaviour is just fine and asked on dev chat. Noel replied: "I can't see that being a worthwhile performance improvement (i.e. the extra code complexity is not worth the gain)"
Comment 14 Telesto 2020-10-19 13:32:58 UTC
(In reply to Buovjaga from comment #13)
> I started thinking the current behaviour is just fine and asked on dev chat.
> Noel replied: "I can't see that being a worthwhile performance improvement
> (i.e. the extra code complexity is not worth the gain)"

But what did you ask specifically? It's not about performance; so reducing speed. (at least not on SSD). This more about causing disk activity. So 'write' actions. They XCU is re-written over and over for every color change..

And that's only they limited context. It's actually written on so many occurances. Shrink a dialog, opening a file, opening context depend menu. Repositioning the dialog. Making toolbar floating.. Changing a setting. Maybe even which window is on top. 

And writing is done separate thread so you don't notice. Except for those who do roaming of some kind (there is ask somewhere) where every profile is saved on central service.

So topic is more about causing huge disk activity (writing). And in context could contribute to wearing SSD's/ flash cards or whatever used for storage. where also they size of they drive matters and and such. 

Yes, browser cache tends to do pretty much the same. But this is a 'stupid' XCU. Based on file size it would fit into memory easily (i'm might grump at high Memory usage at once in a while, but in this case I would make sense :-)
Except there will happen if LibreOffice crashes. Partly solved by interval saving (1 - 2 minutes). However their must be override, as this was problematic for debugging.

Another alternative I proposed was SQLite (somehow not here, but assume similar context). However the advantage was doubted (even SQLite advertising about this )
Comment 15 Buovjaga 2020-10-19 13:38:51 UTC
(In reply to Telesto from comment #14)
> And that's only they limited context. It's actually written on so many
> occurances. Shrink a dialog, opening a file, opening context depend menu.
> Repositioning the dialog. Making toolbar floating.. Changing a setting.
> Maybe even which window is on top. 

Yes, and all of this saving prevents loss of data. Why would you want to make it more risky?
Comment 16 Telesto 2020-10-19 15:00:09 UTC
(In reply to Buovjaga from comment #15)
> (In reply to Telesto from comment #14)
> > And that's only they limited context. It's actually written on so many
> > occurances. Shrink a dialog, opening a file, opening context depend menu.
> > Repositioning the dialog. Making toolbar floating.. Changing a setting.
> > Maybe even which window is on top. 
> 
> Yes, and all of this saving prevents loss of data. Why would you want to
> make it more risky?

If it would be critical stuff of course not, but window position and last used color or last setting doesn't belong to 'needs to preserved at all costs'. For me trade fair trade-off between disk activity and preserving settings. IMHO. And LibreOffice isn't supposed to crash anyhow :-).

BTW: would be nice if you add the chatlog or directly let people comment in the bugtracker.. not big fan of 'second hand' info. People have managed to bend the topic to the desired answer (not saying you do, but people managed to do that so bit skeptical nowadays).

And I personally like some splitting. They topic between. If writing seen not problematic at all; or nothing wrong with it. Or that more about development costs/benefits.

Or what you're suggestion about 'losing' settings.  

You can argue, does it matter. And they answer for me is; yes. As gives insight what the considerations are. How people are thinking. 

Because this can't happen because we will lose 'some data' - as far i'm aware - user settings data not being 'super convincing'. Or even bit sad, actually.
So it's or about proofing data being critical; or costs/benefits. Or about who cares about 2,5 MB writes 2000 a day 365 a year. 

Anyhow still curious how they online variant manages this. I assume this doesn't happen there, else would not really nice for they server I guess
Comment 17 Aron Budea 2020-10-21 02:38:17 UTC
(In reply to Buovjaga from comment #15)
> Yes, and all of this saving prevents loss of data. Why would you want to
> make it more risky?
Considering LO doesn't save the document after each keypress, I'm not sure saving various last-set config values is actually a case of preventing loss of data.

And if the following situation mentioned by Telesto is true, saving megabytes so often is far from great: "A xcu size of 2-4 MB isn't to exceptional causing a crazy amount of disk activity storing mostly trivial things"
Comment 18 Telesto 2020-10-21 08:31:09 UTC
(In reply to Aron Budea from comment #17)
> (In reply to Buovjaga from comment #15)
> > Yes, and all of this saving prevents loss of data. Why would you want to
> > make it more risky?
> Considering LO doesn't save the document after each keypress, I'm not sure
> saving various last-set config values is actually a case of preventing loss
> of data.
> 
> And if the following situation mentioned by Telesto is true, saving
> megabytes so often is far from great: "A xcu size of 2-4 MB isn't to
> exceptional causing a crazy amount of disk activity storing mostly trivial
> things"

FWIW: there are likely by far more instances where it's written. You can you process monitor to check or read the XCU itself they look what's stored.

Noel his position if it it doesn't hurt performance it's no issue (or lets say no big deal) and hard disk are design to handle lots of writes.

Which isn't untrue. And we can add a there likely more unoptimized programs; and there are other instances where stuff is written to temporal files and such.

And we can argue about they load at desktop for typical office desktop. And replacement schedule (in the Western world). So hitting they maximum writes not likely to happen

Or we can also argue against they developing country's. Where assume cloud solutions not being they obvious choice (yet); price/quality of the internet connection. People working with far older (second/third hand) systems, I assume.

If it's easy to prevent, it might be wise to do so. They costs are in they area of more code complexity and more stuff which can break down. And no auto-save stuff is hard to verifier to (Luke Kendall still encountering kind of timer issue with auto-save; kicking in to often once in a while. But time consuming business to track down).

So there is a trade-off here. They whole timer stuff can of course be prevented by saving they xcu in a SQLite database (assuming it does make true what's advertised about reducing writes). But objection here likely be plain xml is 'easier' to access with an editor compared to dumping it into a SQLite database. And of course they downside of updating another external package. An advantage would be that the size of they sqlite should be smaller (as there a columns so non repetitive xml markup stuff)

And there are some other area's where SQLite would be nice (see Julien: bug 134421)

There is no straightforward answer to this, IMHO. Depends on what's valued. It's surely not something most users will notice if changed. So the achievement here isn't unique selling point. More topic out of principle
Comment 19 Buovjaga 2020-10-28 16:43:53 UTC
Ok then