-
Notifications
You must be signed in to change notification settings - Fork 888
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
Extremely slow when exiting? #1841
Comments
Check the task view right before exiting |
It just said no tasks in queue. It looks like the problem was setting
Removing this immediately fixed the issue. Not sure if I should mark this as resolved, since I know the issue but it seems like this would be a bug somewhere. Is there another component I should file on? |
This should probably be looked into but it's far from a priority tbh. It'd be great if you could do a deep dive, figuring out what code is causing this. |
If you have a huge repository such as chromium or a slow CPU you will be easy to reproduce this issue caused by Ranger will update the content of the directories including all parent's paths. After Enabling the I found that the vsc thread is already setup as a daemon, It's not necessary to wait for the tasks because no files were modified during the process of tasks. @toonn Here is my commit, If you think it's a good solution, I will pull request this commit. |
Hmm, those changes had to do with logging. There must've been a reason for making thread destruction synchronous. Could you take another look at #717 to figure out what the reasoning was? |
His primary motivation is to refactor exit handling. Nowadays, PC almost have multiple core CPU, I think the code about vcs should use multiprocessing instead of thread because |
|
This is odd, it appears that checking if the VCS root is outdated takes longer than actually updating the root. See this line_profiler result.
Skipping the check (updating root always) makes both opening a file right after ranger starts and quitting ranger right after ranger starts instant-ish. Is skipping the check the solution? Or should checking Git ignored files be prevented? Or both? |
Is that branch on line 446 taking so much time because of "check_outdated"? We should definitely respect gitignores either way imo. |
Yes it is. See the |
There actually are two similar VCS performance related problems:
It's quite difficult to draw the line between them. Being familiar with the line_profiler allows me to get an insight into what's happening, allow me to explain. 1. Degraded performance caused by repo sizeManifests itself when quitting. Steps to replicate:
Most of the time here (almost 99%) is spent on actually refreshing the VCS root on line number 447. See the profile. Profile of problem No.1 in the chromium repo
I believe most people are actually talking about this problem. If you are having trouble isolating this problem, make sure you don't run into the problem No.2 by temporarily "fixing" it (as suggested in my previous comment) like this. This is not necessary though. Suggested "fix" of problem No.2--- a/ranger/ext/vcs/vcs.py
+++ b/ranger/ext/vcs/vcs.py
@@ -327,6 +327,7 @@ class VcsRoot(Vcs): # pylint: disable=abstract-method
def check_outdated(self):
"""Check if root is outdated"""
+ return True
if self.updatetime is None:
return True 2. Degraded performance caused by
|
Problem 1: Caused by waiting for git process. If you want to "safely exit" ranger, you can't solve the waiting time. To be honest, for now, the design of vcs is so bad, it will cause many problems such as death lock and other issues (#1871). No need to optimize it anymore, refactor the code is the only way to make all issues about vcs gone. I have a plan to refactor vcs using asyncio for my neovim plugin https://github.com/kevinhwang91/rnvimr. I don't desire it will be merged into the master branch of ranger, I just want to happy myself and other users using my plugin. (I am not an expert of python) By the way, thank you for your profile, it inspires me a lots. |
What's the current status on this issue? Are there any workarounds other than setting 'vcs_aware false'? I am experiencing the same issue, even with medium-sized git repos. |
The current status is we're stuck until someone finds the time to work on this. |
I had a similar issue and disabling |
Runtime Environment
Current Behavior
Takes multiple seconds to exit if not more
Expected Behavior
Exits immediately
Context
I'm not sure when but it didn't used to be slow and now it is. This might be a problem with my shell environment, but I'm not sure how to diagnose it / where to find logs.
Possible Solutions
Steps to reproduce
q
Traceback
The text was updated successfully, but these errors were encountered: