I've noticed that the new meson "optlib-based" parser introduced in https://github.com/geany/geany/pull/4013 is extremely slow on macOS - for Geany's ~1000LOC `meson.build`, it takes about 2s to parse which means 2s freezes when editing. It is also slow on Windows, just the freezes are smaller (about 0.5s). Seems OK in the linux VM I'm using but I haven't tried it on anything lower-spec like Raspberry Pi yet.
What should we do about it? For now I disabled the parsers when performing macOS build (https://github.com/geany/geany-osx/commit/0bbb75a8c75426bb2b5576dd047a44bd9f...).
I see the laggy update of the symbol list also on Linux, something between 1-2 seconds and a little spike in CPU usage (Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz).
However, I do *not* see a freeze, only the symbol list needs a little to update but I can continue editing the file meanwhile.
Interesingly, when I generate tags using `ctags meson.build` there is no such lag, it finishes in about 0.05 seconds.
However, I do not see a freeze, only the symbol list needs a little to update but I can continue editing the file meanwhile.
It's single-threaded so I think if you managed to hit the spot when parsing happens, you could see the freeze (even though it seems to be much faster on linux)
Interesingly, when I generate tags using ctags meson.build there is no such lag, it finishes in about 0.05 seconds.
Interesting observation - the reason might be that we don't use the same regex library as the current ctags version. I think we discussed this in https://github.com/geany/geany/pull/3878 where it seemed it didn't make much sense to introduce the extra files from the gnulib (https://github.com/universal-ctags/ctags/tree/master/gnulib) that ctags uses. But if using a newer regex library helps here, it might be an argument for using it. I'll try.
I'll try.
... which might not be so easy to do (especially for meson) because various sources need extra processing:
https://github.com/universal-ctags/ctags/blob/e31feb0d9ccc9e2643465d43a785c1...
So I'm probably not going to work on this.
I see the laggy update of the symbol list also on Linux, something between 1-2 seconds and a little spike in CPU usage (Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz).
I just tried it on Raspberry Pi 4 and there are about 400ms freezes.
In your case the CPU is probably fast enough that you don't see the freezes yet.
However, I do not see a freeze, only the symbol list needs a little to update but I can continue editing the file meanwhile.
It's single-threaded so I think if you managed to hit the spot when parsing happens, you could see the freeze (even though it seems to be much faster on linux)
I think I tricked myself: I've set "autocompletion_update_freq" to 1000ms, so the delay in updating the symbol list was caused by this most probably. Though I reduced it now to 250ms but do not see a freeze yet.
Interesingly, when I generate tags using ctags meson.build there is no such lag, it finishes in about 0.05 seconds.
Interesting observation - the reason might be that we don't use the same regex library as the current ctags version. I think we discussed this in #3878 where it seemed it didn't make much sense to introduce the extra files from the gnulib (https://github.com/universal-ctags/ctags/tree/master/gnulib) that ctags uses. But if using a newer regex library helps here, it might be an argument for using it. I'll try.
And on Linux, we don't use the bundled "gnu_regex" library and so the processing might be faster.
Do we use the "gnu_regex" library on macOS as well?
I built Geany with the bundled regex library but I still don't see a difference. Is there anything special in how to reproduce it or what I could be doing wrong?
Do we use the "gnu_regex" library on macOS as well?
I've just checked and, no, we don't. But macOS versions of various libraries like that tend to be super-out-of-date so I tried with the bundled gnu_regex and this eliminates the problem there completely so updating the build process for macOS to use the bundled gnu_regex might be the cure there.
Still, the performance is a bit iffy on lower-spec machines like Raspberry Pi and possibly Windows (I should note that I tested it on a ARM64 VM where the x86 Geany binary is emulated so for Windows, the actual problem might not be so big there).
So I'll probably just update the build process for macOS and test on native Windows. If the result is OK-ish, it can stay the way it is. If users start reporting issues about the performance, we might just disable these parsers in the filetype config file.
github-comments@lists.geany.org