-
Notifications
You must be signed in to change notification settings - Fork 41
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
Optimize looking for the project root #32
base: master
Are you sure you want to change the base?
Conversation
This way we run all selectors first inside each parent we check, so we can stop once a selector matches. Note: It changes the selector API, but so far I haven't seen the FILENAME argument used anywhere. And in future uses, DIR should be enough for most cases.
This is closer to the original code, but should make no difference for the main use case: when the buffer's major-mode changes some time after it's opened. Now the hook will also fire in non-eproject buffers, but I have hard time seeing the use case. Change the .eproject file, then go to each buffer and flip major modes?
Thanks for this. The change is somewhat complex so I want to test it a bit more before merging, but I haven't forgotten :) |
Sure, take your time, I mostly gave up on using Tramp anyway, it was slow even with this patch. One thing to consider is that this change likely directly contradicts the feature request in #36. |
OK, I think I'm going to incorporate some of these ideas. I will push an update in the next few days and ask for feedback here. |
I think I'm seeing the same problem in my tramp setup. Namely opening a new file under the current project root involves running all the tests again which introduces a lot of latency over a slow tramp link. |
Yeah this shows how slow it can be over tramp: eproject-maybe-turn-on 1 80.410381247 80.410381247 |
The optimization in this pull request is about stopping when you found the first project root, it would still perform the scan for each file, because even if a file is inside a project, it may also be inside some subproject, and inner projects have priority. I think we could skip the check when the file is in the same dir as some other file that's already open, though. The best speedup you can have right now is to just cut down on project definitions. Leave, for example, just one: based on the presence of |
I guess really the optimisation that makes most sense is to check to see if the just opened file meets the criteria for any project currently open first before running the rest of the tests. That way it may take a while on the first file in a tree to be opened but not any ones under it. To be honest the case of subprojects under other projects is not one I deal with and would gladly turn off if I could. As far as cutting down project definitions is concerned it's a bit of a pain as I use the various definitions to control things like compile definitions and other such things. Sounds like I need to code up a shortcut and see if it works. |
Well I've submitted #58 as a potential solution to my performance problems, fully acknowledging it breaks sub-projects. |
When working locally, the process is fast enough, but when using Tramp (over plink), eproject is one of the primary slowdown factors for me.
These changes cut down file opening time from 4-4.5 seconds to 1-1.5, for example, in one "best case" scenario. They don't do much for out-of-project files, though.