This looks (at least to the un-trained eye) somewhat odd. --- a/configmgr/source/components.cxx +++ b/configmgr/source/components.cxx @@ -167,6 +167,7 @@ Components::WriteThread::WriteThread( Thread("configmgrWriter"), reference_(reference), components_(components), url_(url), data_(data) { + SAL_DEBUG("*** create write thread ***"); lock_ = lock(); assert(reference != 0); } @@ -177,6 +178,7 @@ void Components::WriteThread::execute() { osl::MutexGuard g(*lock_); // must not throw try { try { + SAL_DEBUG("*** write config ***"); writeModFile(components_, url_, data_); } catch (css::uno::RuntimeException & e) { // Ignore write errors, instead of aborting: Starting libreoffice, launching writer and exiting produces: debug:5743:1: *** create write thread ***! debug:5743:2: *** write config ***! debug:5743:1: *** create write thread ***! debug:5743:7: *** write config ***! debug:5743:1: *** create write thread ***! debug:5743:8: *** write config ***! debug:5743:1: *** create write thread ***! debug:5743:9: *** write config ***! Which seems quite a lot given the lack of any user-initiated settings change.
Stephan - do you expect that ? prolly a total non-issue, but looks odd =)
The way it works is that every call to the configmgr's commitChanges() initiates a write-back of registrymodifcations.xcu. Actual writing is then delayed by 1 second to allow consecutive calls to commitChanges() to pile up and be processed in one batch. That is, this needs looking at the client code that calls commitChanges() (configmgr/source/readwriteaccess.cxx) to determine why there is so much activity. (I assume it is about storing window positions and such.) (Also, the configmgr code does not remember which values it originally read in from registrymodifications.xcu, so that it cannot detect cases where the changes committed by client code would not change the existing registrymodifcations.xcu, and optimize those writes away. The assumption is that client code does not trigger such "unnecessary non-changes.")
Fair cop - so I'l easy-hack-ize this. The task would be (I guess) to catch and unwind commitChanges() calls during startup that are writing redundant data, and also (ideally) to defer config write-back until after startup has completed - my hope being that we call an explicit flush_() that short-circuits that timeout if we exit. I guess we'd want to hook that into desktop/source/app/ via some new API on any non-published interface implemented by (probably): configmgr/source/configurationregistry.cxx Or - I guess we could overload the semantic of 'flush' there - such that we start out with a much longer timeout to write-back say 10seconds or so - and we reset that on the first flush() - might work better ;-) Thanks ! =)
(In reply to Michael Meeks from comment #3) > Fair cop - so I'l easy-hack-ize this. The task would be (I guess) to catch > and unwind commitChanges() calls during startup that are writing redundant > data, and also (ideally) to defer config write-back until after startup has > completed - my hope being that we call an explicit flush_() that > short-circuits that timeout if we exit. Keep it simple. First, find out what actually triggers those four writes, and whether they are during startup or shutdown or inbetween. Only then, think about any changes, if necessary.
There's another use case that is relevant to this code in this Debian bug report: Bug#774399: libreoffice: aggressive (blocking) config rewrite (lag, slowness) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774399 "With /home on network file system (NFS or similar) libreoffice is lagging miserably on basic operations like when libreoffice just started or new writer document is opened etc., as well as on innocent moves between tabs under [Tools -> Options -> Libreoffice] even when nothing is changed."
(In reply to Chris Halls from comment #5) (1) While writing the configuration changes happens asynchronously in its own thread, it does lock a configuration-wide mutex, so other threads trying to access the configuration can get blocked. (2) What may already help the performance of some use cases (though probably not the above NFS case) is <http://cgit.freedesktop.org/libreoffice/core/commit/?id=e1d78e123b74d37f95b4075b93202b023b4320e9> "tdf#92764 - make configmgr write less noisy." (3) Re "An ugly workaround may be to disable configuration changes completely by setting profile folder read-only" (<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774399#5>): Since <http://cgit.freedesktop.org/libreoffice/core/commit/?id=12f92e6d9ea8bf05bda6d3c42f9b6f0aba000cb0> "Support modification write-back to other than registrymodifications.xcu," you can change the "user:" entry in LO's fundamentalrc CONFIGURATION_LAYERS line from "user:..." (or "user:!...") to "user:*..." to not write any new updates to registrymodifications.xcu (but still read in an already existing one on startup). (And on older versions, just removing the "user:" entry from CONFIGURATION_LAYERS should work to not read nor write registrymodifications.xcu). For better or worse.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp, topicCleanup)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
Hi Michael, I am Komal. I am novice to open source. But really interested to learn and contribute for this organization.Would like to work on this issue? I need help, as to how do I go about it? Thank you!
Hey Stephan, Is this issue still open? Can you help me in resolving it?
(In reply to Komal from comment #10) > Hey Stephan, Is this issue still open? Can you help me in resolving it? The configmgr entry point for comment 4 is RootAccess::commitChanges in configmgr/source/rootaccess.cxx, which calls Components::writeModifications in configmgr/source/components.cxx to actually spawn the asynchronous write-back thread. What's relevant here is to find out why RootAccess::commitChanges is already called during start up.