Only start one tsserver, not one per tsconfig #256
Conversation
|
Historically tide only supported working against one particular version of tsserver (shipped with tide or overridden, custom path set by the user). In such circumstances, this change would make sense. Now however, tide defaults to using the same tsserver as provided by the typescript npm package installed in each and every project it works with. This ensures tide handles things consistently with the projects specific version of tsc, the typescript compiler, automatically. This was a “big” (although fairly silent) feature with lots of discussion and code-review in the PRs. Having only one instance of tsserver would directly invalidate all that work invested in that undertaking, so that’s not immediately desired, at least not for all users. While I can see the argument for preserving resources, it would have to be under very specific constraints, like always using a globally installed tsserver as opposed to the projects’ own. |
|
What about one tsserver per tsserver location instead of one per project? |
|
I have some repos that have multiple Way back when, This, in combination with issue reports like this one (this comment, specifically), gave me the impression that |
|
@lddubeau Are you saying the current behaviour of hashing tsservers on |
|
@sandersn The current behavior of hashing on Hashing on |
|
Assuming that tsserver still has the same problem from microsoft/TypeScript#5828, maybe we should wait until Typescript supports dependencies between tsconfigs, which should be coming in 3.0 or 3.1. That feature exists to make To recap, it seems like there are two reasons to start one tsserver per tsconfig.
If/when (2) is fixed, then I think hashing on tide-locate-tsserver-executable would be more efficient and therefore strictly more desirable, right? |
|
@sandersn Yep, when the 2nd point is fixed it will be better to hash per location to avoid starting so many instances. |
|
@lddubeau Also, if it's been a long time since you observed the bug, it may have been fixed. You can test it by using a constant hash key like "DUMMY" in the I realise it's an imposition to ask you to test whether a bug has been fixed, but I'd like to solve real bugs now (for me, running out of file handles when running VS code at the same time as Emacs) instead of avoiding old bugs that have been fixed. |
|
We could introduce a config Codewise, we assume one server would be used by one project in some places like (process-put process 'project-name (tide-project-name))I guess we could convert it into |
|
@sandersn I tried it just now. It is still buggy. Initially, it looks like it is working but I soon get bizarre behavior, like hitting 100% CPU on @ananthakumaran Yes, I was thinking it should be configurable. It is very likely that users of tide won't be able to move all their projects at once to the new version of TS that has a |
|
Further experimentation with this branch revealed bad behaviour for my Typescript-compiler-development scenario as well (details below). I don't have time for investigation now, so I guess I'll live with the resource usage.
|
There are two things here that are both aimed at reducing the amount of resource clutter: 1. I've seen many tmp files left. Looking at the code, it seems to me like a reasonable thing to get rid of them when a file is saved. I did this via adding `tide-remove-tmp-file` on `after-save-hook`. 2. I also saw that there is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.)
There are two things here that are both aimed at reducing the amount of resource clutter: 1. I've seen many tmp files left. Looking at the code, it seems to me like a reasonable thing to get rid of them when a file is saved. I did this via adding `tide-remove-tmp-file` on `after-save-hook`. 2. I also saw that there is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.) (I added this function onto `kill-buffer-hook`, but if that's too extreme, then a more mild option is to not do that and just let people add it themselves.)
There are two things here that are both aimed at reducing the amount of resource clutter: 1. I've seen many tmp files left. Looking at the code, it seems to me like a reasonable thing to get rid of them when a file is saved. I did this via adding `tide-remove-tmp-file` on `after-save-hook`. 2. I also saw that there is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.) (I added this function onto `kill-buffer-hook`, but if that's too extreme, then a more mild option is to not do that and just let people add it themselves.)
There is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.) (I added this function onto `kill-buffer-hook`, but if that's too extreme, then a more mild option is to not do that and just let people add it themselves.)
There is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.) (I added this function onto `kill-buffer-hook`, but if that's too extreme, then a more mild option is to not do that and just let people add it themselves.)
There is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.) (I added this function onto `kill-buffer-hook`, but if that's too extreme, then a more mild option is to not do that and just let people add it themselves.)
There is a general tendency to accumulate many servers since they're never removed (actually, more than just the servers -- the whole project resources are kept, but the server is the main problem wrt resources). This is also mentioned in ananthakumaran#256. So I implemented a function that scans all buffers and cleanup all projects that have no live buffers. It looks to me like a good idea to do this, since you can just kill old buffers to reduce resource usage. (And killing old buffers is more obvious than explicitly openning the server list to kill old ones, especially since there's no way to tell if a server is used by some buffer or not.) (I added this function onto `kill-buffer-hook`, but if that's too extreme, then a more mild option is to not do that and just let people add it themselves.)
This is how tsserver is intended to be used, according to Typescript team members who work on it. This improves the usability of a long-lived emacs instance after opening many different projects.
I'm testing the change right now and so far performance is better. I don't know whether there are deep-seated reasons to have one tsserver per project root, so I thought that we could discuss that with this PR.
I'm not sure whether initialising
tide-serverwithdefvartoniland updating it withsetqare right since I don't know elisp that well.