You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was thinking about worker_threads in node 11 and wondering if moving the ts-node compiler to a pool of worker threads would ever be faster in transpile-only mode. I'm not sure it's worth it, but I want to share my thoughts anyway.
It'll need --files set to eagerly load files instead of waiting for a require() call. If the app loads its entire codebase at startup, then compilation ordering doesn't matter because you need to wait for every file. But if you're only loading a small subset of the codebase, ts-node's thread worker will somehow need to be smart about compiling the right files first. It could analyze the files it loads for import statements or require() calls and prioritize those files for compilation next. I'm not sure how much of a performance boost you'd get, though.
There's also the issue of moving the entirety if ts-node into the worker thread. Otherwise you have to load typescript into the main thread, which seems costly. But maybe not, since we have to wait for the worker to load it anyway?
Hopefully some day I'll have a chance to prototype this and see if it's any faster.
The text was updated successfully, but these errors were encountered:
This gets more compelling with ESM modules (#1010) since they can be loaded async. As soon as we've parsed tsconfig, we can figure out if worker thread(s) are needed, then launch it/them. Config can be passed as a JSON object. For all transpileModule requests, we can check if a worker is ready, and if so, pass the request to the worker thread.
I was thinking about worker_threads in node 11 and wondering if moving the ts-node compiler to a pool of worker threads would ever be faster in
transpile-only
mode. I'm not sure it's worth it, but I want to share my thoughts anyway.It'll need
--files
set to eagerly load files instead of waiting for arequire()
call. If the app loads its entire codebase at startup, then compilation ordering doesn't matter because you need to wait for every file. But if you're only loading a small subset of the codebase, ts-node's thread worker will somehow need to be smart about compiling the right files first. It could analyze the files it loads forimport
statements orrequire()
calls and prioritize those files for compilation next. I'm not sure how much of a performance boost you'd get, though.There's also the issue of moving the entirety if ts-node into the worker thread. Otherwise you have to load
typescript
into the main thread, which seems costly. But maybe not, since we have to wait for the worker to load it anyway?Hopefully some day I'll have a chance to prototype this and see if it's any faster.
The text was updated successfully, but these errors were encountered: