Created attachment 926822 [details] My make.conf used for my entire system Maintainer suggests that this regression is specific to my Gentoo configuration after reporting at github.com/kovidgoyal/kitty/issues/8584. x11-terms/kitty-0.41.1 has a very interesting regression, at least for me, taking almost 5.5-6 seconds to open or interact with it (such as zooming in or out). I can confirm that version 0.39.1 does NOT have this problem. As stated in my upstream bug report, I bisected this regression to commit 6a169eedd50711a89fe83e76fe905da5c1bbb126, using kitty-9999 (and modifying `--shell-integration="enabled no-rc no-sudo"` to `--shell-integration="enabled"` in the ebuild due to build errors from the presence of no-rc no-sudo). Something I should note is that this issue started occuring after I synced world and transitioned all of my packages from Python 3.12 to 3.13 today (requiring rebuild of kitty). I have had kitty 0.41.1 for quite a while, which is quite strange. I am attaching my make.conf as I do have quite unconventional compilation flags.
(In reply to twine_each563 from comment #0) > Something I should note is that this issue started occuring after I synced > world and transitioned all of my packages from Python 3.12 to 3.13 today > (requiring rebuild of kitty). I have had kitty 0.41.1 for quite a while, > which is quite strange. Doesn't that mean a bisect is useless and can't help here? Kitty is the one thing that hadn't changed, other than being rebuilt?
(In reply to twine_each563 from comment #0) > x11-terms/kitty-0.41.1 has a very interesting regression, at least for me, > taking almost 5.5-6 seconds to open or interact with it (such as zooming in > or out). I can confirm that version 0.39.1 does NOT have this problem. Is that a freshly-built 0.39.1, or a binpkg? > As stated in my upstream bug report, I bisected this regression to commit > 6a169eedd50711a89fe83e76fe905da5c1bbb126, using kitty-9999 (and modifying > `--shell-integration="enabled no-rc no-sudo"` to > `--shell-integration="enabled"` in the ebuild due to build errors from the > presence of no-rc no-sudo). Did you try each commit several times and take the average of the startup time before marking a commit good (no need if it's slow, I guess, just mark bad immediately)? It's possible it's sometimes fine and sometimes not, which would've skewed the bisect.
(In reply to Sam James from comment #2) > (In reply to twine_each563 from comment #0) > > x11-terms/kitty-0.41.1 has a very interesting regression, at least for me, > > taking almost 5.5-6 seconds to open or interact with it (such as zooming in > > or out). I can confirm that version 0.39.1 does NOT have this problem. > > Is that a freshly-built 0.39.1, or a binpkg? > Freshly built. > > As stated in my upstream bug report, I bisected this regression to commit > > 6a169eedd50711a89fe83e76fe905da5c1bbb126, using kitty-9999 (and modifying > > `--shell-integration="enabled no-rc no-sudo"` to > > `--shell-integration="enabled"` in the ebuild due to build errors from the > > presence of no-rc no-sudo). > > Did you try each commit several times and take the average of the startup > time before marking a commit good (no need if it's slow, I guess, just mark > bad immediately)? It's possible it's sometimes fine and sometimes not, which > would've skewed the bisect. I just rebooted my system to take more measurements and they are even more shocking Here are the results of `hyperfine --warmup 2 -N -M 5 '/usr/bin/kitty false'` on these various cases: | | Python 3.12.10 | Python 3.13.3 | 6a169ee^ | 272.6ms +- 9.8ms | 276.3ms +- 10.7ms | 6a169ee | 27.820s +- 0.069s | 27.801s +- 0.032s Looks like python version isn't the issue here. Yes I made sure to change the PYTHON_SINGLE_TARGET when testing against 3.12.10. USE flags for python were ensurepip, ncurses, pgo, readline, sqlite, ssl (rest are not set).
Created attachment 926823 [details] I ran `strace -r /usr/bin/kitty false` and here are the logs
Comment on attachment 926823 [details] I ran `strace -r /usr/bin/kitty false` and here are the logs Line 6028 is where it waits for ~27 s
Oh dear, after installing kitty-0.39.1 (linked to Python 3.13), this issue comes back _now_, so this is inconsistent?
It may be instructive to try use `perf record`.
It seems that compiling with `-O3` is causing issues for kitty 0.41.1. I recompiled with `-O2` and `-Og` and the issue doesn't show. I tried compiling with `-O3` and `-ggdb3` and getting the stacktrace of where it's hanging in GDB. It might not be accurate, I don't really know how to interrupt GDB (and it doesn't work that well with -O3 compilation)
Created attachment 926824 [details] GDB stacktrace from -O3 compiled kitty 0.41.1
I wasn't able to get perf installed unfortunately, couldn't fix the linking errors when emerging (no binpkg of it on the gentoo host either) :(
(In reply to twine_each563 from comment #9) > Created attachment 926824 [details] > GDB stacktrace from -O3 compiled kitty 0.41.1 Is that really the backtrace when it's hanging? (In reply to twine_each563 from comment #8) > It seems that compiling with `-O3` is causing issues for kitty 0.41.1. I > recompiled with `-O2` and `-Og` and the issue doesn't show. > > I tried compiling with `-O3` and `-ggdb3` and getting the stacktrace of > where it's hanging in GDB. It might not be accurate, I don't really know how > to interrupt GDB (and it doesn't work that well with -O3 compilation) Just either.. 1) `gdb -p PID` or 2) `gdb --args /path/to/kitty --any-args-to-kitty` then `r` and `bt` then 3) ^C when you think it's hanging. But of course, running it under gdb means it'll be much slower, so using perf would be best if we can get it to work. (My guess is your perf issue was/is bug 951151 which isn't yet fixed in stable.)
(In reply to twine_each563 from comment #8) > It seems that compiling with `-O3` is causing issues for kitty 0.41.1. I > recompiled with `-O2` and `-Og` and the issue doesn't show. I assume you've tried reopening it several times to be sure it doesn't show? Also, is that literally just -O3 -ggdb3, or is it a bunch more added in?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/binhost.git/commit/?id=50f2305e667ce3913624ee64a4f6fa51f8ff9664 commit 50f2305e667ce3913624ee64a4f6fa51f8ff9664 Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2025-04-28 05:01:45 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2025-04-28 05:02:26 +0000 dola, milou: add perf w/ optional USE=gtk Requested by Sam. Bug: https://bugs.gentoo.org/954894 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> builders/dola/gnome-23/world | 1 + builders/dola/server-23/world | 1 + builders/milou/gnome-23/world | 1 + builders/milou/gnome-v3-23/world | 1 + builders/milou/server-23/world | 1 + builders/milou/server-v3-23/world | 1 + 6 files changed, 6 insertions(+)
Created attachment 926825 [details] Better GDB logs
(In reply to Sam James from comment #12) > (In reply to twine_each563 from comment #8) > > It seems that compiling with `-O3` is causing issues for kitty 0.41.1. I > > recompiled with `-O2` and `-Og` and the issue doesn't show. > > I assume you've tried reopening it several times to be sure it doesn't show? > > Also, is that literally just -O3 -ggdb3, or is it a bunch more added in? It's the same as my make.conf I initially attached, just -ggdb3 added to COMMON_FLAGS. I will retry with a plain -O3 -ggdb3
I have finally found the compile flag that causes this issue--by simplifying COMMON_FLAGS to `-O3 -floop-block -fgraphite-identity -floop-parallelize-all`, I was able to reproduce the issue. Other flags inside my COMMON_FLAGS were -pipe and -ggdb3 when I tested, but I don't think they affect the outcome.
(In reply to twine_each563 from comment #16) > I have finally found the compile flag that causes this issue--by simplifying > COMMON_FLAGS to `-O3 -floop-block -fgraphite-identity > -floop-parallelize-all`, I was able to reproduce the issue. Other flags > inside my COMMON_FLAGS were -pipe and -ggdb3 when I tested, but I don't > think they affect the outcome. graphite is borderline about to be removed from GCC. It's not even worth trying to reduce it. Just stop using it.
I only skimmed over all the posts here, but the tl;dr is that it was caused by graphite, right? Almost tempted to ignore it, but given the lto overlay "legacy" is so widespread, maybe I should filter.
To be clear, that was when kitty itself is compiled with these and not e.g. python, right? I ask given kitty is primarily written in python, but it does have a bit of C too which could affect this and I haven't looked at debug outputs to be sure.
(In reply to Ionen Wolkens from comment #19) > To be clear, that was when kitty itself is compiled with these and not e.g. > python, right? > > I ask given kitty is primarily written in python, but it does have a bit of > C too which could affect this and I haven't looked at debug outputs to be > sure. fwiw I cannot reproduce if all I do is rebuild kitty-0.41.1 with C(XX)FLAGS="-O3 -floop-block -fgraphite-identity -floop-parallelize-all", it startups almost instantly. That's using gcc-15.1 though, could be 14 specific I guess but I don't know what compiler you used given no emerge --info?
Well, was looking at upstream's issue and suppose I could just use kitty's workaround rather than filter either way. (that also answer my question wrt being kitty itself)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=32c5e4cd4953c21ccaf198313615f0408db0b5f6 commit 32c5e4cd4953c21ccaf198313615f0408db0b5f6 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2025-04-28 09:25:26 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2025-04-28 09:29:51 +0000 x11-terms/kitty: filter graphite flags for now kitty did a workaround, so it probably won't be needed next version (albeit I'd suggest to stop using these flags). Considered backporting the workaround, but think will just filter after all. Note I haven't been able to reproduce myself, but haven't tried much (not looked at debug, X vs wayland, gcc-14 vs 15 and such, would rather not spend time on this). Closes: https://bugs.gentoo.org/954894 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> x11-terms/kitty/{kitty-0.41.1.ebuild => kitty-0.41.1-r1.ebuild} | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
OP, if you can narrow it down a bit more, that'd be appreciated for the record.
