Navigating code is slow and hogs CPU; Linux gtk2, app is maximized on 3840x2160 display

[Lastique]

Simply moving the cursor up and down across a C++ file feels slow and consumes a lot of CPU. It seems like the UI is updated in about 10 fps, and the CPU load is about 10% (where a full all core load is 100%). The CPU load seems to be spread across multiple cores.

In comparison, Sublime text in the same scenario, with the same C++ file, consumes about 4-5% CPU and is much snappier. KDE Kate is even better at 2-3% CPU.

While at it, here are the memory consumption stats as well:

• CudaText: 170008K
• Sublime: 53364K
• Kate: 35928K

In all editors a single same C++ file was open. CudaText was used in the out of the box configuration (only the path to Python library was configured).

Kubuntu 20.10, KDE, CudaText 1.122.6.0 linux-x86_64-qt5, fpc 3.2.1. Tools used in tests: Sublime 3.2.2 build 3211, Kate 20.08.2. Core i7 2600K, 16 GiB RAM.

[Alexey-T]

1-- I have CPU Intel i3 3Hz. what is yours? 2-- will it be faster if you set in 'Plugins/ Options Editor' option 'links_hilite' to false? I am not sure but it may give lower cpu usage? 3-- option 'lexer_folding_max_lines', if set to lower value- will disable folding and give faster scroll (if file size is big)

@jairo-martinez maybe you can test it too.

[Lastique]

1-- I have CPU Intel i3 3Hz. what is yours?

As mentioned in the OP, it's Core i7 2600K (at 4.4 GHz).

how many lines it has the C++ file that you are using?

The file is https://github.com/boostorg/atomic/blob/dbb5c7cf7c062f2681d82bd45f87f6f1acceb6eb/include/boost/atomic/detail/atomic_impl.hpp. But I tried with other, smaller files and there was no difference.

[Lastique]

2-- will it be faster if you set in 'Plugins/ Options Editor' option 'links_hilite' to false? I am not sure but it may give lower cpu usage?

No, it doesn't make any difference.

3-- option 'lexer_folding_max_lines', if set to lower value- will disable folding and give faster scroll (if file size is big)

I tried setting it to 0 and it also made no difference.

I can tell that I have a 3840x2160 display, and have CudaText maximized. If I make it a small window (like 1/8 of the screen) the performance becomes much better. CPU consumption drops to 1-2% and the UI feels much snappier. It looks like CudaText redraws the whole text view on update.

BTW, the other text editors mentioned in the OP were also tested on the same display maximized.

[Alexey-T]

my biggest monitor don't allow me such resolution 3K-4K, so I cannot test this now.

[Lastique]

Try making it a window, then resize and move it so that it is larger than your screen. E.g. move it down and right, then drag the upper left corner of the window left and up, then repeat a few times.

[Alexey-T]

I found that scale of window by X (800x600 -> 1800x600) don't slow down the rendering. scale of window by Y (800x600 -> 800x1200) DOES slow down (600->1200, slower by 2 times). so the reason is: Canvas.TextOut (or LCLIntf.ExtTextOut) is slowing down all render. I also see that debugger stops inside the ExtTextOut (most of the time, in 80%).

I cannot solve it, TextOut (ExtTextOut) on linux is not known code to me.

the same slowdown occurs on gtk2 and qt5. so it is mostly Lazarus issue of gtk2/qt5 codes.

[Alexey-T]

@Lastique Made some optimizations. not very big. maybe you see some speedup? one of optimizations is for text with tab-chars. (leading tab-chars in line).

beta http://uvviewsoft.com/c/

[Lastique]

I see no improvement, code navigation is as slow as before. Tested Qt5 version 1.126.2.0 on the same machine.

PS: You can test performance improvements on your end as you are able to reproduce.

[Lastique]

Also tested 1.126.4.0, it's the same as well.

[Alexey-T]

if you have Minimap:on, it will be faster now-- in 1.127.

[Alexey-T]

Because of #3338 the work speed may be faster. but rendering is the same slow one.