SUMMARY After opening a 144MB file in kwrite and browsing its contents kwrite starts to consume 100% CPU and all the available memory. See #410129 STEPS TO REPRODUCE 1. Open a big file in kwrite 2. Press Ctrl End OBSERVED RESULT One of my CPU cores stays at 100% usage. Kwrite memory usage is very high, reaching ~8GB when I killed it. You can see KSysGuard attachements with this info in #410129 EXPECTED RESULT Browse file contents. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.12.3 ADDITIONAL INFORMATION -
Does the shell script contain i) binary data, and / or ii) very long text lines?
Yes, it has binary data and very long lines $ wc -L SoapUI-x64-5.5.0.sh 862 SoapUI-x64-5.5.0.sh $ file SoapUI-x64-5.5.0.sh SoapUI-x64-5.5.0.sh: POSIX shell script executable (binary data)
I can't replicate this on kwrite built from kate git master. Isaac, can you please retest and confirm if this is still an issue.
Created attachment 132904 [details] kwrite 20.08.2 CPU and memory usage
Just tried again (20.08.02) and this time CPU only spiked when scrolling through the file. IMO memory usage is still huge as you can see in the attached screenshot: that ~4GB step was the memory used by kwrite. Overall responsiveness is way better than when I opened this issue, but still system felt a bit laggy until I closed kwrite. I'm currently using: Operating System: KDE neon 5.20 KDE Plasma Version: 5.20.2 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.0 Kernel Version: 5.4.0-52-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8665U CPU @ 1.90GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620
Dominik does this extra info assist in diagnosing what might be causing this?
Requested information was added with comment 5; changing status for inspection.
*** Bug 413565 has been marked as a duplicate of this bug. ***
*** Bug 421935 has been marked as a duplicate of this bug. ***
We optimized some aspects, but large files still consume big chunks of memory. If that should change, we need ideas and patches for that, otherwise we keep that as is, it is not unreasonable, we work well for the normal use cases. https://kate-editor.org/post/2020/2020-07-18-contributing-via-gitlab-merge-requests/