Created attachment 175623 [details] document with many footnotes There is an exponential increase in lag time associated with the addition of the footnotes/endnotes category in the Navigator, particularly when editing the footnotes, when the document has a large number of footnotes. See attached footnotes document. Introduced by https://gerrit.libreoffice.org/c/core/+/122970 in bug 144788. Makes LO unusable for larger documents with many footnotes.
I'd say the number of bookmarks in the example file contributes more to the cause of lag than the number of footnotes. I think we need some guidance from UX.
(In reply to Jim Raykowski from comment #1) > I'd say the number of bookmarks in the example file contributes more to the > cause of lag than the number of footnotes. The document works fine in 7.2.x. I agree that in this specific document, the bookmarks, which happened automatically, for some reason, through copying and pasting, triggered the lag. But several real world documents with no bookmarks are also exhibiting the severe lag. I have not yet determined what exactly about them triggers the lag except that it has something to do in combination with the footnotes category. The lag does not happen pre-7.3 alpha.
The lag also does not happen with the current development app image dated 2021-08-22, which is before the footnotes category got implemented.
The attached document is probably not the best one for this particular bug. It might actually be demonstrating a different regression than the footnote one. The lag is removed in my real world documents by not executing the 'case ContentTypeId::FOOTNOTE:' statement in sw/source/uibase/utlui/content.cxx.
Created attachment 175652 [details] replacement document with many footnotes Created a new sample document without bookmarks.
Specifically, it seems to be the command 'rFormatFootnote.GetFootnoteText(*m_pWrtShell->GetLayout())' that is the issue. Maybe I'm mistaken, but from what I can tell, the 'for (SwTextFootnote* pTextFootnote : rFootnoteIdxs)' loop is iterating through all footnotes/endnotes for every edit. Might it be possible and more efficient to only do that on only an insertion or deletion of a footnote/endnote and only change the specific footnote/endnote on an edit.
(In reply to David from comment #6) > Specifically, it seems to be the command > 'rFormatFootnote.GetFootnoteText(*m_pWrtShell->GetLayout())' that is the > issue. Yes, that is what I have discovered as well. > Maybe I'm mistaken, but from what I can tell, the 'for (SwTextFootnote* > pTextFootnote : rFootnoteIdxs)' loop is iterating through all > footnotes/endnotes for every edit. Yep, every second when focus is in the document it is filled and checked against the content in the tree to determine if a change was made in the document. See IMPL_LINK_NOARG(SwContentTree, TimerUpdate, Timer *, void) and SwContentTree::HasContentChanged() > Might it be possible and more efficient > to only do that on only an insertion or deletion of a footnote/endnote and > only change the specific footnote/endnote on an edit. Might be possible and definitely would be more efficient. Same goes for all the other member lists. I optimizing the Footnote member list code but chrono tests showed no improvement in the effort. The big time consumer is the GetFootnoteText call.
Here is "optimized" code to fill the footnotes member list. No significant difference in execution time between the existing code. https://gerrit.libreoffice.org/c/core/+/123433
FYI: the build failed on gerrit. I see the case statement now only has 1 'for' loop. But the lag is still there. The new statement 'rFormatFootnote.GetFootnoteText(*pLayout)' seems to take as much time as the old 'rFormatFootnote.GetFootnoteText(*m_pWrtShell->GetLayout())'. Looks like the big improvement will need to come from the loop not being run every second or at least not iterating through the whole list every time.
Opening the document takes on my (actually fast) machine with a development debug build a couple of minutes while 7.2 has no lag. The console is spammed with warn:xmloff:229407:229407:xmloff/source/draw/shapeimport.cxx:346: unknown element urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:soft-page-break This is clearly a bug. But how can UX guide you?
Here is a patch that should help reduce lag: https://gerrit.libreoffice.org/c/core/+/124036
Hi David, I put the in the patch mentioned in my previous post. It seems to improve UI response. Testing with gtk3 backend still shows lag for backspace and delete keys. x11 and qt backends don't exhibit this lag.
This seems "bisected" already per the initial report. Is bibisecting really needed? If not, please remove the "bibisectRequest" keyword.
Let's assume so, if there's still something to bibisect, please reset the keyword.
@Jim Awesome work! You deserve the Programmer of the Year award for the second year in a row! With your recent work, it looks like the attached files are working very quickly. An initial save, close, and reopen may be needed, but after that, there is almost no waiting to be able to edit the files after opening them. The footnote tree is populated instantly when expanded, and there is only a very slight hiccup every second when editing the footnotes. There used to be a delay of like 10 or 15 seconds when expanding the footnote tree. The extreme number of bookmarks in the original file also seem to have no effect on the speed now. I think this bug report can now be closed. I suspect that the recent work may have also taken care of some other bug reports related to lag time.
(In reply to David from comment #15) > @Jim > Awesome work! You deserve the Programmer of the Year award for the second > year in a row! > David, Thanks! TDF "Fantastic People, Fun Project" "Awesome People, Awesome Project" > The footnote tree is populated instantly when expanded, and there is only a > very slight hiccup every second when editing the footnotes. There used to be > a delay of like 10 or 15 seconds when expanding the footnote tree. The > extreme number of bookmarks in the original file also seem to have no effect > on the speed now. > > I think this bug report can now be closed. I suspect that the recent work > may have also taken care of some other bug reports related to lag time. The bookmarks were definitely a contributing factor to the lag. Correcting a fill issue with them helped a bunch. For some real painful lag try opening https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.odt It has 16173 fields. After it fully loads (takes minutes for me) navigating around with the arrow and page keys and the Navigator works without lag but try editing the document with the Navigator open and feel the lag uhg :(