*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY Resizing embedded terminal requires quite some CPU power and gar show lags STEPS TO REPRODUCE 1. Open kate and display an embedded terminal (F4) 2. Open a suitable CPU monitoring tool like htop in a another standalone terminal 3. Grab the resizing line in the embedded terminal and move it to make it bigger or smaller OBSERVED RESULT The CPU monitoring tool shows CPU usage for kate to jump close to 100% for the application in a single core. kate lags in updating its window when the terminal is displayed aside (vertically) of the editor panels. No change if the terminal is empty or displays something. EXPECTED RESULT CPU usage is increased slightly and no lags can be noticed when the terminal is vertical. SOFTWARE/OS VERSIONS GPU Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) Kernel Version : 6.10.8.zen1-1 Plasma Version : 6.1.4-1 KDE Version : 24.08.0-1 Frameworks Version : 6.5.0-1 Qt5 Version : 5.15.15+kde+r4-1 Qt6 Version : 6.7.2-2 Wayland Version : 1.23.0-1 XOrg/Wayland Version : 24.1.2-1 Mesa Version : 1:24.2.2-1 LibVA Version : 2.22.0-1 LIBVA_DRIVER_NAME=iHD ADDITIONAL INFORMATION Two monitors setup with different scaling factors. Not sure this is relevant.
can't reproduce with a terminal on left sidebar or bottom sidebar. In any case, reassigning to konsole
Konsole works fine and I cannot reproduce the problem by resizing a konsole all alone. Maybe the problem is in how kate handle konsole during resizing.
> Maybe the problem is in how kate handle konsole during resizing. Nothing special about that so its unlikely the problem is there. Can you try to use perf or hotspot to profile Kate when it is slow? - Download the appimage https://github.com/kdab/hotspot/ - Make sure `perf` installed - Start Kate - Start hotspot appimage. File -> Record data. Then select "Attach to Process" in the top left corner, then select the kate process and click start recording - Switch over to Kate. Do the thing which makes it slow. - Switch back to hotspot and stop recording. click "View results". Then either share the flamegraph (View -> Export), or the perfparser file (File Save as...).
[code] $ perf record -o /home/user/perf.data --call-graph dwarf,8192 --aio -z --sample-cpu --mmap-pages 16M --pid 7327 Permission error mapping pages. Consider increasing /proc/sys/kernel/perf_event_mlock_kb, or try again with a smaller value of -m/--mmap_pages. (current value: 4096,0) recording failed after 012.12039ms: Failed to record perf data, error code 255. [/code] I think I am still missing something in my ArchLinux box. I don't know perf, anyway.
Just run this on the command line directly instead (slightly modified): perf record --call-graph dwarf,8192 --aio -z --sample-cpu --pid $(pidof kate) It will create a perf.data file in the directory you are in. Open the perf.data file in hotspot and then export the flamegraph/perfparser file
Done. See attached file. BTW, there has been a(n unwanted) reboot before this test and I cannot reproduce the lagging problem anymore. I can still see kate using close to 100% of the CPU while resizing the konsole panlel, while no konsole process is using less than 1% of CPU.
Created attachment 173549 [details] gzipped perfparser file This is the required perfparser file.
Thanks. In the attached file, I don't see anything that is taking too much time. I can see that the resizing takes some time and it might consume 100% of 1 cpu for a short while but that is okay. Moreover, its all happening in Qt itself so there isn't anything we can do about it. Probably there was some other reason for the lagging. If you can't reproduce it, then I would consider this bug RESOLVED/WORKSFORME.
OK. I could reproduce the lag. I am attaching the gzipped perf.data.perfparser .
Created attachment 173557 [details] gzipped perf.data.perfparser
The point seems to be the terminal panel been full of text.
You seem to be using file-backed scroll history. Reflowing that seems to be quite slow.
Hmmm... I still think this is a bug. My terminal history was at the time of my test less 64KB (likely even less than 8KB). How can that lead to the lag on a i7 with 24GB RAM and NVME disks?
I have a less powerful cpu, but can't get it to lag after running ls -l /usr/bin about 10 times. So maybe the history is bigger than you think
I just checked the actual cache file size (I never did that so far). My settings say I should be storing it into "~/.cache/konsole". But that directory is actually empty. I am now doubly puzzled.
That is expected I think as the file is temporary. At least thats what it says in the tooltip when enabling it in the settings.
Since you are on Arch, building konsole yourself is trivial. I would suggest adding some printfs in the scrolling code to help might make the situation more clear. Building konsole is just - git clone https://invent.kde.org/utilities/konsole - mkdir build && cd build - cmake .. - make -j$(nproc) # run this only in `build` dir when rebuilding - ./bin/konsole # run it The file where the relevant logic lives https://invent.kde.org/utilities/konsole/-/blob/master/src/history/HistoryFile.cpp
(In reply to Waqar Ahmed from comment #16) > That is expected I think as the file is temporary. At least thats what it > says in the tooltip when enabling it in the settings. I don't think so. I am inspecting that directory **WHILE** konsole is open and displaying some content. I would expect that cache file to be there while konsole runs. Or am I missing something?
Created attachment 173585 [details] Output for "lsof | grep konsole > lsof-konsole.txt" Output for "lsof | grep konsole > lsof-konsole.txt" With "Scrollback file location: System temporary location (/tmp).
Created attachment 173586 [details] Output for "lsof | grep konsole > lsof-konsole2.txt" Same as above, but with "Scrollback file location: User cache directory (~/.cache/konsole).
Even if I am setting "Scrollback file location: Custom: /tmp/konsole-backlog" I cannot find that file while konsole is running with non-empty scrollback content.