Description: It takes a while before the document gets responsive after saving Steps to Reproduce: 1. Open attachment 123999 [details] (bug 98663) 2. Make a small edit 3. Save the file and take notice of the required to be responsive after the save is completed (accordingly to the status bar). Compare with Version: 4.3.0.4 Actual Results: Writer is unresponsive for 8-10 sec after saving has completed. With LibO4.3.0.4 it's only a few sec Expected Results: Should be responsive in a few sec Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 5.5.0.0.alpha0+ Build ID: 076ed447f694239d5c67adee528ea6e471d909ff CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-09_23:54:20 Locale: nl-NL (nl_NL); Calc: CL and in Versie: 5.2.2.1 Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Locale: nl-NL (nl_NL); Calc: CL Its a bit crashy between between 4.4.0.1 and 5.1.0.3 (could properly test) LibO 4.3.7.2 seems quite fast, but Version: 4.3.0.4 seems to be faster User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Created attachment 134230 [details] Callgrind output from master Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: ab27953d9ef2076e0acd43ed4ba6652732794777 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 23rd 2017
Sadly not bibisectable because of the crashiness. Tried repos 4.4, 5.0, 5.1, 5.2 on Windows. Still confirming the slowness. Version: 6.1.0.0.alpha1+ (x64) Build ID: 8fae8a6cd73b7262c3739bd4acc5c72b54934ff1 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-22_22:52:50 Locale: fi-FI (fi_FI); Calc: group
Unresponsiveness is not very long now, maybe the fix for bug 117066 affected it?
(In reply to Buovjaga from comment #3) > Unresponsiveness is not very long now, maybe the fix for bug 117066 affected > it? Sadly, no change for me, still slow (progress bar is quite fast, but not the Window shows "not responding" for a while Version: 6.3.0.0.alpha0+ Build ID: 3083fe569f96bf0289da1e9d0ef7da15ab22e2f6 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-04-16_01:39:55 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL STR 1. Open the attached file 2. CTRL+S 3. Start typing after the progress bar disappears..
I've already optimised this save process in the context of some other bug (but using exactly the same document) - it is down to 11s or less for me.
Indeed, it takes ~12 seconds in Version: 6.3.0.0.alpha1+ Build ID: 9c7fac47aacb0877c7d212217089a680400c1377 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Sorry, back to unconfirmed. Writer is unresponsive 8-10 sec AFTER the the disappearance of the saving progress bar. The Windows shows 'not responding'. Total time until responsive 45 seconds Version: 6.3.0.0.alpha1+ Build ID: b4d2131bc643a5f13e0367d4e43ae5603369ddf6 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-05-20_07:48:24 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
(In reply to Telesto from comment #7) > Sorry, back to unconfirmed. > > Writer is unresponsive 8-10 sec AFTER the the disappearance of the saving > progress bar. The Windows shows 'not responding'. Total time until > responsive 45 seconds I can type 1-2 sec after progress bar completes, so WFM for me. Version: 6.4.0.0.alpha0+ (x64) Build ID: 7272b9f752cb74757d6ed504202eefccc589f804 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-01_03:59:41 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
(In reply to Buovjaga from comment #8) > I can type 1-2 sec after progress bar completes, so WFM for me. Same result for me with Version: 6.3.0.0.beta1 (x64) Build-ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: en-US (de_DE); UI-Sprache: de-DE Calc: threaded
Sorry, still having the same issue Version: 6.3.0.0.alpha1+ Build ID: 63b39fe87644587210214198fb67d6b3fb3343c5 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-05-27_01:42:59 Locale: it-IT (nl_NL); UI-Language: en-US Calc: CL Saving as such is no issue. Rather fast, but I can't edit -> "not responding" appears in the title. Tested it with a x64 and x32 build.. Maybe something related to Windows 8.1?
(In reply to Telesto from comment #10) > Calc: CL Might be a red herring, but what if you deactivate OpenCL?
No repro with Version: 6.4.0.0.alpha0+ (x86) Build ID: 93477d1a963e38e3319013e43835a8ffef200972 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-06-02_10:16:52 Locale: it-IT (nl_NL); UI-Language: en-US Calc: threaded Setting to NEEDINFO for now, want to recheck this (to be sure it's really gone)
[Automated Action] NeedInfo-To-Unconfirmed
Back to NEEDINFO (see comment 12)
Seems ok Version: 6.4.0.0.alpha0+ (x86) Build ID: c45d477b0a0038d9c25176cf7cff299e5ddf3a7a CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-09-30_05:06:55 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL Closing as WFM