-
Notifications
You must be signed in to change notification settings - Fork 82
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
project node constantly being reinitialized for each newly opened file #237
Comments
@tjarvstrand I've removed the parts of the code which refresh the node after the project node is already open and you open a new file within that project and nothing seems to immediately break. Why does edts need to refresh the project node when you open a new file within that project? |
Well, motivation is to update code path, xref etc if you open a file in a newly created directory (eg. app) in your project. Needless to say, this could be improved immensely, but as it stands I'm a bit hesitant to just remove it. |
I can confirm the issue. Just to clarify, the performance degradation seems due to the way the
If the node is already registered, the |
IIRC, I think that what it all boils down to is that it would be nice to monitor the file system and apply only the necessary changes as opposed taking the shotgun approach an re-initialize the whole system. That way the incremental refresh should hopefully not affect performance at all. |
Edts initializes the node (or a new node) every time a new erlang file is opened. Initializing a new node involves loading edts onto the node, but if the user twice quickly file while a long-lived background process is running, it will get killed by the code loading mechanism. An example when this can happen is when the xref plugin initializes for a large project. The strategy to always initialize the node was discussed in sebastiw#237 and one motivation to do node_init always was "to update code path, xref etc if you open a file in a newly created directory (eg. app)", see the comment sebastiw#237 (comment) This commit attempts to not break code path updates, while avoid errors caused by the code loading.
Edts initializes the node (or a new node) every time a new erlang file is opened. Initializing a new node involves loading edts onto the node, but if the user twice quickly file while a long-lived background process is running, it will get killed by the code loading mechanism. An example when this can happen is when the xref plugin initializes for a large project. The strategy to always initialize the node was discussed in sebastiw#237 and one motivation to do node_init always was "to update code path, xref etc if you open a file in a newly created directory (eg. app)", see the comment sebastiw#237 (comment) This commit attempts to not break code path updates, while avoid errors caused by the code loading.
Hi,
I've been running an older version of edts for a while but decided to upgrade.
I then noticed that opening a new file (in the same project) took longer than before (short story: project node is reinitialized).
There seem to be a couple of issue behind this. I saw this in *Messages*:
It looks like edts is constantly initializing a new node.
edts-api-get-nodes checks whether "foo" is a member of ("foo@bar" ...), which means edts-api-node-registeredp always returns nil. See edts-api-get-nodes.
I changed that to this (which removes the "@..." from the list of nodes.
This should mean that edts-api-init-project-node goes into refresh mode instead of init.
The next thing was if I open (follow a dependency, use the module lookup function, open a file directly, ...) a file it starts edts-mode for that buffer. And that nowadays does this:
I.e. it'll reinitialize the project node every time a file is opened the first time.
For a small project that's likely quick, but for a bigger it takes a while and CPUs run hot (xref etc. I suppose).
Here's the log from when setting the edts-log-level to 'debug:
Thankful for any help. What would be the intended behavior here?
Cheers,
Klas
The text was updated successfully, but these errors were encountered: