Description: While monitoring the file access of LibO with process monitor I noticed that LibO is accessing the disk a lot. For example * Soc/sob/sog files are accessed when selecting a shape in draw * images_tango.zip will be accessed when adding a table (for the toolbar) * some xml and ui files However, I keep wondering why. Why are small (most used) configuration files and the default theming accessed from the disk and not from RAM. The disk access would be be reduced quite a lot (and I would expect some performance gains) The default share folder only weights +/-50mb (without extensions & gallery). So it should be possible. That memory increase seems acceptable to me. Steps to Reproduce: 1. Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: - User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
I'm not a developer but it sound a good idea to me. I set status to NEW and put "needsDevAdvice" keyword. I think Michael Meeks could give a proper answer to this enhancement request. good idea or not?
I asked on the -dev channel and Noel recommended to close this as wontfix. Something that came to my mind is that now the line between disk and memory is starting to blur with the new type of hardware being released.
(In reply to Buovjaga from comment #2) > I asked on the -dev channel and Noel recommended to close this as wontfix. > > Something that came to my mind is that now the line between disk and memory > is starting to blur with the new type of hardware being released. Out of curiosity: where can I read something about this 'new type of hardware'. I probably missed something..
(In reply to Telesto from comment #3) > (In reply to Buovjaga from comment #2) > > I asked on the -dev channel and Noel recommended to close this as wontfix. > > > > Something that came to my mind is that now the line between disk and memory > > is starting to blur with the new type of hardware being released. > > Out of curiosity: where can I read something about this 'new type of > hardware'. I probably missed something.. Here is one technology from Intel and Micron: https://en.wikipedia.org/wiki/3D_XPoint
Yes - sadly we're not yet in the era of NVRAM machines - and (I guess) the "corrupted profile" problem becomes far worse in this era ;-) Then again - if we are taking significant seek latency here, we should prolly try to load these config settings - ideally in a thread after startup & initial document load I guess to avoid getting the seek latency later.