Comments (10)
That is normal. There are 4 different scenarios in which we bring up a node process:
- One permanent process for servicing all real-time requests for the editor (code completion, find declaration, etc...).
- One temporary process each time a build is triggered to gather diagnostics (this is a workaround for a bug in the TypeScript services).
- One permanent process for compiling source files to JavaScript quickly (setting up a new node process each time we build like 3 above would be too slow).
- One temporary process for each reconciler (there is one reconciler per editor, so these can really add up).
I'm considering having the reconcilers all share a single node process. That would take this down to just 4 max processes at any given time. Right now there will be as many node processes as their are TypeScript editors open + a few more for the other stuff. If that is a problem please lemme know and I'll prioritize changing this design.
from eclipse-typescript.
Ok
Is it the same for each eclipse project or for the workspace ?
If I've got 10 projects, is there 40 process ?
If not there's no pb for me
from eclipse-typescript.
Oh right, there can be additional processes for each project as well. To be honest I haven't tried out multiple projects yet. We'll be doing it soon but haven't had a chance to try it out yet. I suspect many things wouldn't work properly. For example, dependencies across projects definitely wouldn't work.
If you have 40 projects with the TypeScript nature enabled then you would have a minimum of 20 processes. This would spike up to 30 when building all of them. Then each editor window gets its own additional process. Hmm, this is sounding pretty ridiculous now :) I think I should probably make the reconcilers' share processes as well. The reason I'm scared to do so is there are bugs in TypeScript that prevent it from properly keeping up with changes to files. Having separate processes per window makes it harder for these issues to impact the user. But perhaps the cost is too high.
from eclipse-typescript.
For the moment it's not problematic for me. I've only 4 projets in same time.
Thanks for the response
from eclipse-typescript.
I'va also see that many times, when I exit eclipse, some node process are not killed, so eclipse process still run.
from eclipse-typescript.
I have a proposal, although I'm not totally sure about the feasibility.
At the moment the plugin keeps a cache of language services (and classifiers also) in the eclipse layer, each one keeping a reference to a node process. The proposal is to move that cache to the other side of the bridge, and keep the list of language services (and classifiers) in the node process, reducing the connection to a single node.
In node, it might be possible to keep just one LanguageServiceHost per project and then one instance of LanguageService for each LanguageService that is currently kept in the eclipse layer.
Of course the node process should then be converted to receiving requests on a socket instead of stdin/stdout as it is now, to be able to concurrently serve requests from the various eclipse threads.
This would provide several benefits:
- Reduce the number of node processes;
- Reduce the amount of memory used, as a the moment each node process keeps a copy of project .ts files (plus all internal typescript structures plus all the node overhead). At least the node overhead and possibly the LanguageServiceHost file infos could be reduced. This, however, is the point I'm not so sure about, as possibly updating the file infos from different threads could produce undesired behaviors (see next point, however).
- In eclipse it could be possible to have only one delta listener, as there is only one copy of the LanguageServiceHost to be updated. This would reduce processing overhead and, most importantly, the number of interprocess communications between eclipse and node (at the moment each delta is processed several times, one for each bridge instance).
What do you think?
R.
from eclipse-typescript.
I'm using a lot of projects and eclipse leaks node processes like it's no tomorrow.
It would be really nice to have this fixed somehow
from eclipse-typescript.
At best, we could reduce the number of node processes down to just 2. Since node is single-threaded, we will always need one which is just for quick requests and one which is just for slow requests.
It would also not be possible to keep just one language service host per project since the builder and editor actually want to see files in different states. The builder always operates on the saved file state whereas the editor always operates on the currently being edited state. That means each project would still need at least 2 different language service hosts.
Taken together, these proposals could still definitely reduce the number of node processes necessary if not for one really big problem: the TypeScript services themselves have some bugs that prevent it. There is a bug in the current release that makes it cache semantic information too aggressively. For the current plug-in code I've worked around this issue in the builder by creating a new language service each time we get semantic diagnostics. For the editor, the bug doesn't seem to have a negative impact, so it can keep a permanent language service. For the reconciler, it is absolutely impacted by this bug (several guys here have complained about it) and there there is no good workaround that maintains performance so we create one node per reconciler to minimize the damage: if the reconciler is impacted by the bug you can simply close and reopen the editor to "fix" the issue. However, once 0.9.2 is out, we can start consolidating all these node processes down to just 2-3 per project.
My concern with this report is not the number of node processes (which we'll fix once the next version of TS is out) but that the processes are being leaked. That really needs to be tracked down and fixed. Does anyone have a simple repro for that? I haven't seen it when I last checked (a few weeks ago). Does it involve shutting down eclipse while a certain process is running or is it just trivial to repro (perhaps due to a recent regression)?
from eclipse-typescript.
In my example it was just to open a five projects at the same time. Eclipse spawned more and more processes and when I closed eclipse the node processes did not die.
from eclipse-typescript.
Good catch - this was super leaky. I added a shutdown hook so that this shouldn't happen anymore.
from eclipse-typescript.
Related Issues (20)
- NodeJS custom location
- VCLJSTeam.VCLJS Traduzir esta página
- TypeScript 2.1 update break ContentAssist
- support glob in tsconfig
- Missing actual install step in "Installation" section HOT 1
- Use tsconfig option conflict with compiler project specific.
- Error using moduleResolution = 'node' in tsconfig file HOT 1
- tsconfig supports *.js files but fails in plugin HOT 4
- Upgrade to TypeScript 2.1.5 HOT 13
- Can provide options to ignore such errors:Cannot find module 'xxxx' HOT 1
- Installing Typescript Plugin from a JAR file (for air-gapped networks)
- Compiling all workspace when saving a ts file HOT 1
- Settings not availabe HOT 4
- IllegalStateException: The node process has crashed. HOT 2
- Error Occured while Building Workspace for using TypeScript HOT 1
- Cannot add Eclipse TypeScript Plug-in to Eclipse HOT 1
- NullPointerException PresentationReconciler.getDamagedRegion(PresentationReconciler.java:132) HOT 3
- Update Eclipse installation site HOT 2
- Eclipse Plugin Update Site Not Found HOT 3
- eclipse_typescript的更新站点已经无法使用了,请帮忙解决,我们需要新的可用插件下载安装地址
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eclipse-typescript.