Created attachment 141424 [details] File with saving slowness Split from https://bugs.documentfoundation.org/show_bug.cgi?id=98665#c28 because result is different from the original report. It is slower to save on Windows (2 min) than Linux (30 sec). Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: c8c74a0b4ca6f3a3619f423b6548c80c52392ae0 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 15th 2018
Created attachment 141425 [details] Callgrind output from master
Looks like a bibisectable regression to me, or did I miss something Crash with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL No repro with Version: 4.3.7.2 Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68b
(In reply to Telesto from comment #2) > Looks like a bibisectable regression to me, or did I miss something > > Crash with > Versie: 4.4.7.2 > Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 > Locale: nl_NL > > No repro with > Version: 4.3.7.2 > Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68b I bibisected against the crash with bibisect_win_44 and got this range: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a42aa52acbbff738a00299de172ca85cb001d840...2d92a84a6aac37e34d1699fdebe0270468b4f746 Maybe I should bibisect crash vs. slowness. It is already about 2 mins in 5.0.
(In reply to Buovjaga from comment #3) > Maybe I should bibisect crash vs. slowness. It is already about 2 mins in > 5.0. This was more relevant, because the time to crash is what matters in this period. Slowness starts at https://cgit.freedesktop.org/libreoffice/core/commit/?id=692c886f937c525d6bfcb541917a5114b085efa9 Same blame for bug 91925 Adding Cc: to Björn Michaelsen
The fix in the mentioned commit is not negotiable, I think: Cursors should properly disposed. So this wont be fixed as a regression, because doing something not wrong is worth being slower. Maybe having less cursors around etc. might be worthwhile but that is hardly relevant for a specific document. Closing this as WONTFIX.
(In reply to Björn Michaelsen from comment #5) > The fix in the mentioned commit is not negotiable, I think: Cursors should > properly disposed. So this wont be fixed as a regression, because doing > something not wrong is worth being slower. > > Maybe having less cursors around etc. might be worthwhile but that is hardly > relevant for a specific document. > > Closing this as WONTFIX. It's still a performance bug, IMHO. Maybe not something you're responsible for.. I would leave it open without regression & bibisect keyword.. Instead of burying the issue
(In reply to Telesto from comment #6) > (In reply to Björn Michaelsen from comment #5) > > The fix in the mentioned commit is not negotiable, I think: Cursors should > > properly disposed. So this wont be fixed as a regression, because doing > > something not wrong is worth being slower. > > > > Maybe having less cursors around etc. might be worthwhile but that is hardly > > relevant for a specific document. > > > > Closing this as WONTFIX. > > It's still a performance bug, IMHO. Maybe not something you're responsible > for.. I would leave it open without regression & bibisect keyword.. Instead > of burying the issue Exactly. I was just coming to say that and revert the status change. We have to track this in any case.
Well, that only works if there is something relevant to debug here. The bisect showed that doing proper cleanup of UnoCursors slowed things down. So its a hint that this document does weird things with UnoCursors. Opening the doc, I find it has some ~1500 bookmarks alone, most of which seem garbage. Hint: Dont do that to your documents if you care about performance.
This one should be retested after the merge of. https://gerrit.libreoffice.org/#/c/70092/ https://gerrit.libreoffice.org/#/c/70112/ See also 122926 Also related to bookmarks.. I guess
(In reply to Telesto from comment #9) > This one should be retested after the merge of. > https://gerrit.libreoffice.org/#/c/70092/ > https://gerrit.libreoffice.org/#/c/70112/ > > See also 122926 > > Also related to bookmarks.. I guess Time to save is still 30 sec on Linux (the point when UI is not greyed out anymore) Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 3b518953a8141b0d5043c2f3996a92956fdc3a47 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 2 April 2019
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/eb7c9bcda2a4324a682114a1f38e4761c665cbdc%5E%21 tdf#117066 Saving ODT document with ~1500 bookmarks is slow, part 1 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/a1bba53d6fbc56537da0296c27db5cc443c8bca7%5E%21 tdf#117066 Saving ODT document with ~1500 bookmarks is slow, part 2 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c40a0d8c80a6b6d1354b0dc9695a8476a0a15599%5E%21 tdf#117066 Saving ODT document with ~1500 bookmarks is slow, part 3 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/1d556ff84dce01531ee334dc1408cebe50e97d22%5E%21 tdf#117066 Saving ODT document with ~1500 bookmarks is slow, part 4 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/306758ab3e06f7c730bb1625c2f3fcce7a912fa3%5E%21 tdf#117066 Saving ODT document with ~1500 bookmarks is slow, part 5 It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Time comparison before and after: Before ( LibreOfficeDev 6.3.0.0.alpha0 cca2e42926a14ec27c663cd0f495dccb7607d6f9 ): real 1m25,091s user 1m33,869s sys 0m14,891s After ( LibreOfficeDev 6.3.0.0.alpha0 ea3a1b075154a665d30aaac6513812ceb839f64b ): real 1m0,637s user 1m2,967s sys 0m6,338s in a previous versions ( LibreOfficeDev 6.1.0.0.alpha1 3a801799536e6870f2fb111b1cc00b9575a35a39 ): real 1m47,699s user 1m54,325s sys 0m15,394s so it's getting better overtime...
The last thing I was working on didn't pan out, couldn't get it to be stable enough, so I'm not going to be working on this anymore, feel free to leave open or close as you see fit.
Thanks, marking as fixed.
in Version: 6.3.0.0.alpha0+ Build ID: 26e85974a0287ab5869e7ff0145a66b853d66a02 CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded it takes real 2m33.702s user 0m0.000s sys 0m0.015s while in Version: 6.2.0.1.0+ Build ID: 2c0c0794a8e287497e460f3f1e6bcba585d675d4 CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded it takes real 3m44.190s user 0m0.000s sys 0m0.015s nice improvement!