-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add autodetection (only load plugin when editing a Django project) #13
Comments
Thanks for your input and I appreciate you trying to increase the visibility of this plugin. Before going to the trouble of optimizing something, I spend a little time determining whether or not the time spent on the optimizations will make an impactful and noticeable difference without sacrificing usefulness. SetupI built my dev box in 2015 and use a nightly build of Neovim. The CPU is an Intel Core i3-4170 CPU @ 3.70GHz, and it has 8GB of RAM. I copied all of the scripts to a mechanical HDD that spins at 7200 RPM. I feel that I wasn't fast and loose about leaning on the hardware for performance. I'm not grooming my configs for the profile. The stats below are based on my full config. If you look through my configs (not up to date), you will notice that I'm not very mindful at all about the startup time (another plugin I made) or file loading time. I mainly rely on the notion that anything (outside of keystrokes and very frequent actions) taking less than 200ms is acceptable. ProfilingI used the following to load files: :argadd **/*.py
:profile start profile.log
:profile func *
:profile file *
:silent argdo edit
:profile pause
:noautocmd qall! I got the file count using: find . -name '*.py' | wc -l Here's how long it took to load the detection script (from an SSD):
Non-Django filesI profiled the loading of 1677 non-Django python files at once from a randomly chosen pyenv Here's the profiled Click to see full function
It was called 6708 times, and cumulatively ran for ~1.4 seconds (with the bulk of the time spent on scanning), to determine that 1677 files were not related to Django. In each case, it completely skips the block that sets the The function that does the directory scanning: Click to see full function
Most of the time was spent in the loop, skipping directories that were already checked. It could cache the results and never run the loop again, but as you issued in your challenge, we'd want to be able to still handle a case where the user starts a new project, right? If you agree that it's unrealistic for someone to open 1677 files of any type in Vim, you might agree that it's unreasonable to think that 1.4 seconds is "slow" in this case. Django scriptsThis profile is based on a Django project that had 520 python scripts The Click to see full function
Oof, this one takes about 8 seconds in total. However, if you expand it, you'll see the time is spent on Actually here's the scan function because I now feel like I'm boasting without proof: Click to see full function
I tried to figure out what exactly was taking so long to load when setting the python filetype, but it looks like it's sprinkled throughout a few python plugins, including nvim's builtin python plugin. The slowest plugin was my first plugin that I'm a bit ashamed of performance-wise. But, it only took about 800ms in total and
A cumulative 325ms to load 520 files doesn't look bad to me. The same fileSince nvim didn't really like me trying to open 1677 files at once, I ran another simpler test by opening an empty python script and wiping its buffer 1000 times (from the same working directory). let i = 0
while i < 1000
let i = i + 1
split empty.py
quit
bwipeout empty.py
endwhile This was the impact of the detection function:
This looks like an anomaly to me because it seems that the function is called twice each time the file is loaded. In the earlier runs, it was called four times per file loaded! I suspect it might be another plugin that's misbehaving. This is something I would investigate, but I would say that it still ran quickly enough for opening the same file 1000 times. One last time but with just one file:
I know it's not quite a solid test, but that run time is pretty close to the zero second delay that I personally feel that I experience when loading a file. Whatever delay you are experiencing might be caused by another plugin. ConclusionI guess it's fast enough? The script for scanning non-Django files could be faster, but the question remains: will the time spent on the optimizations make an impactful and noticeable difference without sacrificing usefulness? Personally, I don't think so. Going by the numbers I see, I definitely want to avoid holding any of my plugins to the standard vim-polygot wants to set. If a plugin only has It's absolutely true that you save time from not loading a bunch of little scripts, but the time saved is negligible when compared to almost anything you could be waiting for in a lifetime. I will address some things you mentioned here:
The comment that I included should indicate that this is known.
If you benchmarked this and actually experience slowdown because of this plugin, your problem is most likely outside of my influence.
Due to a change in my career, I haven't had to work on Django that much either. I never noticed a slowdown because of this plugin and I have a tendency to hang onto sessions with a lot of buffers.
As you saw above, this is how it already works.
If this was done, html files related to Django would have already loaded the
This is basically the case now. If you're saying you'd prefer that the filetype not be autodetected by default, I would be fine with a PR to add an option to cause the detection to immediately return, but not flat out disable the autocmd. |
This project could not be included in vim-polyglot because it does too much on startup, even if the user is only editing a text file or a Javascript file.
(I am also reluctant to keep it installed, for the same reason. I use Vim for lots of different things, and only use Django occasionally.)
Suggestion:
Challenges:
The text was updated successfully, but these errors were encountered: