-
Notifications
You must be signed in to change notification settings - Fork 137
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
[bug]: Constant CPU usage #362
Comments
Didn't see the last picture |
I see the same behavior, CPU usage without zinit for a zsh shell on my end is 0. With zinit is high, the same pattern reported by @mustaqimM. The constant CPU usage stops when an application is run in zsh shell, for instance vim/nvim. On my end the idle CPU usage of vim/nvim is 0. So keeping vim/nvim instance open in a zsh shell has lower overall CPU activity than keeping the shell at prompt waiting for user input. @vladdoster How did you hunt that down? Any tool/methodology or commenting different parts of code? |
@reportaman Noted. Thanks for the information! I've finally got some time to dig into this tonight and over Labor day weekend. To answer your questions: I started a new Zsh instance with debugging via: exec zsh --interactive --login --verbose --xtrace and saw this output over and over when idle. There is another tool I like for debugging, but will be cumbersome/frustrating to use if you aren't super familiar with using a debugger. That said, observability is useful even if you're just debugging your personal ZSH configuration. |
Have a feeling this is related to #315? |
This can be lowered down by making scheduler sleep for a longer time like 5
seconds. It currently sleeps for 1 second.
wt., 1 lis 2022, 12:46 użytkownik vladislav doster ***@***.***>
napisał:
… Have a feeling this is related to #315
<#315>?
—
Reply to this email directly, view it on GitHub
<#362 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABOE4CHR3PYJZ6K72GHLRJLWGD7KXANCNFSM567OJ6QA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@psprint whats the reason for running the scheduler so often? |
It's for wait ice - it's checked every second to run tasks in proper time
slots. I guess that it could be changed to sleep for exactly the needed
time or to sleep longer after e.g. fitst 5 seconds.
czw., 3 lis 2022, 01:15 użytkownik vladislav doster <
***@***.***> napisał:
… @psprint <https://github.com/psprint> whats the reason for running the
scheduler so often?
—
Reply to this email directly, view it on GitHub
<#362 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABOE4CHR6JPFHQ3Y5S4W5T3WGL7ZLANCNFSM567OJ6QA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@vladdoster: the fix is in #409. |
Can it be event based, or can a user use zinit in a way to avoid this loop altogether? It might look like low overhead, but that's subjective. At the moment an idle zsh shell with zinit installed executes 2 million+ aarch64 instructions per second on my computer. A power user who has tens of shell sessions open over time would see battery dipping... Or if someone were to port their zshrc to something like raspberry pi or other smaller computers they will have to get rid of zinit. |
Yes the fix is in #409, @poetaman . It changes the sleep time to 10 seconds and makes a short circuit exit if no tasks. |
@vladdoster A significant slowdown on my system (with fan kicking in) made me do more testing. Haven't tested this with @psprint's patch but currently there is bug that increases the number of instructions executed per second by 2+ million instructions for every When the system slowed down I had already spent many hours Not sure if the plugins have anything to do with this. Here's what
|
@poetaman I saw there might be a bug in fast-syntax-highlighting. You might try removing it and see if anything improves? |
Oh, wait. Also a bug in |
@vladdoster I commented out all those plugins, the issue and its scale remains same with zinit (each |
@vladdoster If you mean https://github.com/zdharma-continuum/zinit-annex-readurl, I don't have it in my plug-ins for zinit. So the source of bug seems zinit core itself... |
Have you seen this? Just shooting from the hip. zsh-users/zsh-syntax-highlighting#895 Btw, how are you calculating instruction count? Could you paste output of following? zmodload zsh/zprof
# 1. cd to a few directories / what causes slowdown
# 2. copy zprof output to clipboard
zprof | pbcopy
# 3. paste in this issue
# 4. profit?! ;^) |
Using CPU performance counters, that's the most accurate one can get. On macOS this comes integrated with top, on Linux they have it under procfs (to give users more fine grained information). Ready for some bonus boring video? In the left shell you will see zinit_2million_per_cd.mp4
|
I can reproduce this on Linux with the current main branch at 68a6b42. The culprit is the chpwd hook set for eric@xrb /tmp/test % sched
1 Tue Aug 15 20:16:12 ZINIT[lro-data]="$_:$?:${options[printexitvalue]}"; @zinit-scheduler following "${ZINIT[lro-data]%:*:*}"
eric@xrb /tmp/test % cd test
eric@xrb /tmp/test/test % sched
1 Tue Aug 15 20:16:16 ZINIT[lro-data]="$_:$?:${options[printexitvalue]}"; @zinit-scheduler following "${ZINIT[lro-data]%:*:*}"
2 Tue Aug 15 20:16:16 ZINIT[lro-data]="$_:$?:${options[printexitvalue]}"; @zinit-scheduler following "${ZINIT[lro-data]%:*:*}"
eric@xrb /tmp/test/test % cd ..
eric@xrb /tmp/test % sched
1 Tue Aug 15 20:16:19 ZINIT[lro-data]="$_:$?:${options[printexitvalue]}"; @zinit-scheduler following "${ZINIT[lro-data]%:*:*}"
2 Tue Aug 15 20:16:19 ZINIT[lro-data]="$_:$?:${options[printexitvalue]}"; @zinit-scheduler following "${ZINIT[lro-data]%:*:*}"
3 Tue Aug 15 20:16:19 ZINIT[lro-data]="$_:$?:${options[printexitvalue]}"; @zinit-scheduler following "${ZINIT[lro-data]%:*:*}" Lines 2486 to 2498 in 68a6b42
I think a general fix would be to only add a sched entry if there's not already one present in As a side note, I used |
What happened?
Hello, I noticed with even just a plain zinit .zshrc, around 0.7% per shell is used; this increases with more plugins.
Steps to reproduce
.zshrc
with contents:Relevant output
No response
Screenshots and recordings
Zinit with no plugins:
![swappy-20220819_070853](https://user-images.githubusercontent.com/24436622/185548190-ec00c008-c7ec-4b16-a1f5-c8037e23ecce.png)
Zinit with plugins:
![swappy-20220819_081746](https://user-images.githubusercontent.com/24436622/185555620-6cac27b2-664b-4428-ac1c-777039f406b6.png)
zsh -df
:Operating System & Version
OS: linux-gnu | Vendor: unknown | Machine: x86_64 | CPU: x86_64 | Processor: unknown | Hardware: x86_64
Zsh version
zsh 5.9 (x86_64-unknown-linux-gnu)
Terminal emulator
alacritty
If using WSL on Windows, which version of WSL
No response
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: