New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow startup of new instances. #830
Comments
The most obvious thing to check first is the GPU drivers. Temporarily switch to using the open source noveau (i think its called) driver and see if it makes a difference. The next step is to instrument kitty code to see where the slowdown is occuring. Notable startup code is in main.py (the _run_app function) and glfw.c (the create_os_window() function). Stick some timing prints into those and see where the slowdown is happening. |
Nouveau was tested and it resulted in no difference.
It's been a while since I've dabbled in Python, would you care to show me what to insert? |
from time import monotonic
print(monotonic(), 'xxx') insert that in a few places in the _run_app function to see where the time is being spent. I'm going to guess it is in create_os_window() which you will find in glfw.c |
Naming might be slightly off, but I've done my best to document them. python 3 . -1
python3 .
The major hang up seems to be from the init_glfw, specifically before the module returns. Edit: I figured that it'd probably be clearer if I linked the modified code, so it becomes much clearer what executes where.
|
glfw_init is in glfw.c line 588. There you will find the slow function is glfwInit() which initialises the glfw toolkit that kitty uses. You can trace that further in init.c where you will probably find the slowdown in _glfwPlatformInit() which will be in x11_init.c (assuming you are on an X11 system) |
Also, I note that compiling the OpenGL shaders (load_all_shaders()) seems to be very slow on your system, it takes 0.26 s. Considering that it only has to compile ~ 300 lines of shader code, that is insane. |
Or maybe I am misreading your trace, the lines of concern are:
Not sure exactly what those correspond to. |
Let me just plop code associated with those parameters below.
and
I'll investigate this somewhere in the next few days. |
OK so its not the shader compilation it is somethin in create_os_window as I initially suspected. You can find that in glfw.c |
Returns seem normal, Will delve into the x11_init.c next. |
Code for the timed module highlighted
The highlighted statement gets posted right after the slow down, but the time calculation seems acceptable, so I went ahead and moved the timer up, upto the point where it got posted before the slowdown.
Seems to be the problem. I figured I'd try removing those lines all together and it seems to fix the slow startup.
|
Kitty seems to have a really slow start up on some systems, where as it is unaffected by this on others,
does not appear to be related to slow hardware.
I have a salvaged two core Baytrail system. that pulls acceptable start up time.
The system that I experience this under however runs the following:
Now the unaffected system mirrors this software configuration except for the fact that it runs an integrated CPU and thus utilizes the mesa drivers instead of the NVIDIA ones.
Utilizing the
-1
parameter bypasses the slow start up, as it hooks into an existing process.Testing was conducted via executing
time kitty fish -c exit:
with a potential-1
I default to the fish shell, but replacing it with sh or zsh has identical timing.
Unaffected Baytrail system timings.
Now the affected system
It seems that CPU utilization is throwing some kind of wrench in the loop, but I cannot say.
The text was updated successfully, but these errors were encountered: