[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||79045_79...@mail.ru --- Comment #15 from Roman Kuznetsov <79045_79...@mail.ru> --- 14 sec for the opening the file in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: e4d23c27288b99c3ed3cfa332ff308b31c01f97d CPU threads: 4; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Jumbo Intel Core 2 Quad 9450 here -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 --- Comment #14 from Vasily Melenchuk (CIB) --- I was not able to reproduce original testcase: in my dev environment in debug build I let Calc to load document for ~ 30 mins without any success and then stopped. But I do not think that this performance issue is related to row height recalculation. See previously attached perf.svg.bz2: >ScFormulaCell::InterpretFormulaGroupThreading (917 samples, 56.57%) >ScDocRowHeightUpdater::update (1 samples, 0.06%) First one is a multiplication of matrix done in multiple threads most of the time. Second is a row height calculation during load, it is almost impossible to find on this svg. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 --- Comment #13 from Kohei Yoshida --- There is a lot to unpack here, so this will be a bit lengthy. First off, as Kevin correctly explained, that use-optimal-row-height flag corresponds to the flag to re-calculate optimal height when a cell value changes during editing, and it is not a flag to indicate whether the row heights should be re-calculated on load. Doing so would (as we now know) cause a noticeable performance degradation during file load for everyone, which is not a good look. If the standard is not clear about when this flag should trigger recalculation in my opinion that point should be further clarified in the standard. As for improving performance on row height re-calculation, to me it’s a lost cause since that process is already known to be very expensive involving getting font metric information as well as other attributes of the text for every character involved. Caching certain font metric information was attempted in the past, which may improve performance in certain situations, but it’s unclear how much that would help with the row height re-calculation. Still, any attempt to speed it up would not come anywhere close to not running it. As for a potential fix, the logic Kevin suggested is a reasonable approach, though I’m not sure whether we should check for the row height being 0. That’s a corner case that would not happen when Calc is the generator since setting the height to 0 would set the hidden flag while leaving the original height unchanged. I would just leave it as the generator’s responsibility to never set the height to zero, or leave out the value in case the desired value is not clear. But it’s just my opinion. I think either approach is fine. Now, here is the bad news. The current ODF import filter code is notoriously hard to work with since it was built on (IMO) the wrong architectural basis of basing it on (mostly) UNO API. UNO API is designed for run-time automation with change notifications firing everywhere. Making it built on UNO API unfortunately resulted in significant performance issue not to mention making it very very difficult to follow, understand, and make significant design changes to the code since UNO promotes the idea of decoupling all the moving parts. My hope at the time was to slowly switch from populating the content via UNO API to doing the same directly with ScDocument via its import-time specialized accessor ScDocumentImport. You see some trace of my earlier attempt in this part of Calc’s code. If someone is up for it, my suggestion would be to try to populate the content via ScDocumentImport instead of using UNO API. ScDocumentImport has direct access to ScDocument’s private parts, and is designed to populate the document content without unnecessary change notifications etc. I did make quite some inroads toward using ScDocumentImport to speed up loading for other, non-UNO based import filters, but unfortunately I only made small progress with the native ODF import filter. It may be a good idea for someone to pick up the torch to continue further. Alternatively, it may be actually simpler to introduce an internal configuration option to toggle row height re-calculation on load (defaults to off, of course) to satisfy the use case in tdf#62268. Fixing the import filter code would be the ideal approach, but I’m not sure if anyone would want to even touch that code… I wouldn’t, at least not willingly. ;-) Only those with enough bandwidth could tackle that code, and I don’t have much bandwidth these days unfortunately. As a final aside, my frustration with working with this code also motivated me to re-architect the ODF import filter in orcus, which can be turned on in Calc with some effort (right now it’s disabled). But that filter is only 10 to 15% complete, so using that would be a long shot. Maybe someday it will become somewhat feature complete, but who knows. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=14 ||4515 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 --- Comment #12 from Kevin Suo --- ODF Spec. ''' 20.394 style:use-optimal-row-height The style:use-optimal-row-height attribute specifies that a row height should be recalculated automatically if content in the row changes. The defined values for the style:use-optimal-row-height attribute are: •false: row height should not be recalculated automatically if content in the row changes. •true: row height should be recalculated automatically if content in the row changes. ''' Well, from this ODF standard, this attribute defines that the row height should be recalculated if the content in this row is changed (i.e., at the time of editing), rather than when the document is open. At time of editing when the row height is recalculated, a new row height value is determined and is saved to the ODF file. At file open, the application should use the defined row height value directly rather than recalculating each of them. For all new ODF spreadsheet docs there is a defined row height for each row. The rational of recalculating the row heights at file open as in the commit of bug 62268 is that for some mannully generated ODF files there is no row height value defined in the xml file, normally because those programs are not professional OpenDocument Producers and they simply want an ODF Viewer like Calc to calculate the row height for them when the file is open by the user. And I agree that in such case (if there is no defined row height value) Calc should help to recalculate. So, consider both bug 62268 and the properly generated ODF filed, the fix should be: if rowHeight and rowHeight>0: finalRowHeight = rowHeight else: if useOptimalRowHeight: (recalculate row height) finalRowHeight = reCalculatedRowHeight else: finalRowHeight = defaultRowHeight The improvement of the speed for the recalculation of row height is another issue. However, for large spreadsheets even the fastest calculation may still cost a lot of time and CPU circles as it need to loop into each row and each cell. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 Kevin Suo changed: What|Removed |Added Status|NEEDINFO|NEW -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 --- Comment #11 from Thorsten Behrens (allotropia) --- Agree. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 --- Comment #10 from Kevin Suo --- At least Calc should not add the style:use-optimal-row-height="true" attribute to each row for documents newly created. Currently, Calc add this attribute by default to each row. This attribute should be set only if the user explicitly select a row / some rows, then right-click and select "Optimal Row Height", or if the user select rows and then double-click on the row headers. Otherwise this attribute is useless. I see the main reason the row height get re-calculated is that if this attribute is true is that for programly generated documents if this attribute is explicitly added it is true that the row heights should be recalculated, see bug 62268. -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 Thorsten Behrens (allotropia) changed: What|Removed |Added CC||t...@libreoffice.org Status|NEW |NEEDINFO --- Comment #9 from Thorsten Behrens (allotropia) --- I would argue this is not fixable (as a reported regression), since the underlying problem is the slow row height calculation. Now, _not_ re-calculating row height creates another set of bugs (see bug 62268), so how about we re-purpose this as a increase-row-height-calculation-speed? As it stands now, I'd otherwise be inclined to close as WONTFIX (better be slow & correct in layout, than the other way round). -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 128204] ODS file opens slow but after on/off Wrap text automatically it opens very fast (because of adapting row height)
https://bugs.documentfoundation.org/show_bug.cgi?id=128204 Kevin Suo changed: What|Removed |Added CC||suokunl...@126.com Blocks||125077 Summary|ODS file opens slow but |ODS file opens slow but |after on/off Wrap text |after on/off Wrap text |automatically it opens very |automatically it opens very |fast|fast (because of adapting ||row height) --- Comment #8 from Kevin Suo --- I can still reproduce this issue on latest 7.1 branch and also 7.2 branch. The slowness seems to be in adapting row height. I guess it was "on/off Wrap text" which removed the style:use-optimal-row-height='true', that is why at that case is opens fast. The "adapting row height" is very annoying. For me a 5MB ODS file may take one minute to open which stops at the adapting row height stage. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=125077 [Bug 125077] [META] regressions introduced by row height recalculation on document load -- You are receiving this mail because: You are the assignee for the bug.___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
