-
Notifications
You must be signed in to change notification settings - Fork 9
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
Pet performance issue #12
Comments
Opening the first python file of a project takes a little longer because it needs to populate the cache, but once the cache is populated, the 2 functions should run substantially faster. Is this not the case for you? |
I would have also expected that, but it is not the case. |
I see this problem too - it took me a while to understand why opening of my Python files is so incredibly slow. |
It's expected to take a few seconds when opening the first python file in a project, but opening subsequent python files within the same project should be relatively quick due to the aggressive caching. The slowness mainly comes from the number of subprocesses Emacs has to open in order to parse the config and cache files. It's a problem if opening subsequent python files within the same project is slow, but I'll need more information such as your project layout and benchmark numbers to even confirm it is indeed a bug. There are opportunities to speed up opening even the first file, but it's not worth the effort. Emacs 29 will come with a number of improvements that will enable this. |
I see this in Windows 10 where Emacs is generally extremely slugish (had to turn off pet, lsp-mode and a few other things to even get to a point that I don't need to wait 30 seconds to open each file ...), so I guess you can disregard my comment. In Linux/WSL it works fine - there is a slight delay when pet is enabled in the python-mode-hook but nothing dramatic. |
OK, I did some more testing - in Linux, under WSL but all files are on the Linux filesystem (not accessing NTFS, that would be very slow). I have multiple files from the same project open already, my hook is starting
( It is clear that something isn't cached because those executables should be the same, regardless of which file from the project I open. I had 3 other Python files from that project open already - and it is this slow whenever I try to open another one. For info:
|
Oof, OK I see why the problem happens for me. WSL automatically "helpfully" adds the content of Windows PATH variable to the Linux PATH. So when I didn't create the virtual environment for the current worktree yet, Once I have created a local virtual environment, the file opening time dropped from 20 seconds to about 2s. Still a bit sluggish but much more manageable. This is the profile after the the cache has been populated: my-pet-hook 1 2.163337651 2.163337651
pet-executable-find 10 2.1546226499 0.2154622649
pet-flycheck-toggle-local-vars 1 0.880342973 0.880342973
pet-project-root 29 0.07939641 0.0027378072
pet-pre-commit-config 18 0.0552564690 0.0030698038
pet-pre-commit-config-path 18 0.055118069 0.0030621149
pet-find-file-from-project 18 0.0549999620 0.0030555534
pet-find-file-from-project-root 18 0.0546787409 0.0030377078
pet-use-pre-commit-p 10 0.0317966749 0.0031796674
pet-virtualenv-root 11 0.028649633 0.0026045120
pet-pre-commit-config-has-hook-p 8 0.024069906 0.0030087382
pet-flycheck-python-pylint-find-pylintrc 1 0.005421203 0.005421203
pet-flycheck-checker-get-advice 173 0.0002698909 1.560...e-06
pet-flycheck-setup 1 0.000240067 0.000240067
eglot-ensure 1 2.3442e-05 2.3442e-05
pet-system-bin-dir 10 9.872...e-06 9.872e-07
pet-report-error 1 3.47e-06 3.47e-06 I am not sure whether it makes sense to add any sort of fix/workaround for this since this is a Windows/WSL specific nonsense and not really pet's fault but maybe mentioning this in the README would save some hair to some future user. Alternatively, if it detects poetry/pipenv but doesn't find a virtual environment, it could emit a warning message - "Hey, idiot, you forgot to run However, caching the found executables (and not only the virtualenv root) per project would be likely still good idea that could make pet a good deal snappier. At 200ms per binary it is still 2 seconds delay when opening a file. Such cache would probably make it usable even in Windows once one "pays the price" for populating the cache with the first opened file. |
I'm going to close this. Please reopen if this is still an issue. |
This is still an issue on the latest commit for me. With pet-mode, I've switched from |
Description
I have the problem that my pet setup has some performance issue, i.e., it takes a long time in every python buffer in my project until the
python-mode-hook
functions are run. I think this is the case since I've started using pet.This code in my
python-mode-hook
takes 640ms! when I open a python file and when I revert the bufferWhat I also see is that if I execute in my scratch buffer, I see that it take > 600ms.
setting the default directory just to my home dir reduces the time to just 30 to 40ms (still a lot IMO).
Reproduction steps
Expected behavior
I see that pet related functions in my python mode hook +
(flycheck-mode 1)
take a long time (>2s).If I open a python file that is not part of any project, I don't have this problem.
PET version
pet 20220917.2111 installed Executable and virtualenv tracker for python-mode
Emacs version
29.0.5
Desktop (please complete the following information):
see #10
System tools versions
see #10
The text was updated successfully, but these errors were encountered: