Performance issues

[domoritz]

Are there known performance issues of ts-node? I have a medium sized typescript project and we used to compile with tsc and then run tests with mocha. However, ts-node seems to be better because we a) don't need to have a plugin to support sourcemaps and b) generate js and js.map files before we run the tests. So I tried ts-node with mocha in gulp but now builds take ~20s. I suspect that this is because all the files have to be recompiled. Is this a known issue?

[blakeembrey]

There shouldn't be any performance issues, but there is a large start up cost for compiling the project. Also, all the files are currently kept in memory which can be a memory overhead so it's not recommended for production (yet). There's a few things that can improve this - for example, storing transpiled output into files and allowing the code to skip all type checking in production. These have no been implemented.

The speed overhead should roughly equate to the time spent in tsc and gulp before.

[domoritz]

Thank you @blakeembrey! I'll experiment a bit more and see what I find.

Just to tell you about the performance issues I'm seeing.

$ time tsc
tsc  2.92s user 0.11s system 139% cpu 2.178 total
$ time mocha build/test
mocha build/test  2.03s user 0.14s system 101% cpu 2.139 total
$ time npm run test
npm run test  23.85s user 0.78s system 104% cpu 23.497 total

[blakeembrey]

@domoritz Thanks for the detail! That looks like and insane difference, I'll experiment with it more. There's certainly some optimizations that I should look into, so I'll do that ASAP for you too.

[domoritz]

@blakeembrey Awesome. I really like this plugin btw. I am woking on vega-lite and the switch to ts-node was done in vega/vega-lite@0e66b31. Let me know if you have any questions about it.

[ksikka]

I'm working in rather large coffeescript/typescript codebase that takes ~40 seconds to compile (I'm not sure why it takes so long - that's an important but separate issue.) The implementation of typescript-require caches compiled files to disk. Switching from typescript-require to ts-node adds 4 minutes to the time it takes to run our tests (usually 7 minutes, now 11 minutes). Just wanted to post this in case others are experiencing similar things, in which case it might make sense to add a persistent cache.

[blakeembrey]

@ksikka What version are you using?

@ksikka @domoritz I'll do a complete refactor to a different compilation model using TypeScript, but there's trade-offs on all sides. For example, out of band require calls to TypeScript files won't be type checked, and the CLI will always need to continue re-use the current model since it's a bit of a hack to make the CLI work. The other option I was thinking about is enabling a --production flag to skip type checking and just enable the transpiler which is much faster.

Most likely I'll do a refactor to use both, the initial node file load will use a TypeScript program instance and output to the filesystem for a more reasonable overhead in production. Subsequent out-of-band require calls won't be able to use the same instance of the program though (since it would have been written to disk and discarded), so they'll fall back to the transpiling only (maybe with a warning?). Using the --production flag will only use the transpiler. The CLI will continue to use the language services. Any thoughts from anyone watching this?

If I do this, would you guys mind trying it out?

[blakeembrey]

@ksikka Are you using the type checking of TypeScript at all with typescript-require?

[domoritz]

@blakeembrey I'd definitely try it and report the performance numbers.

[kirill-konshin]

I am experiencing same issue -- using

mocha --recursive --require ts-node/register ./src/**/*-spec.ts

Eats extra ~20 seconds comparing to regular build which uses Webpack and ts-loader.

[blakeembrey]

Can you guys try v0.5.4? I haven't completely rewritten it, yet, so it's just an incremental change that I believe will improve things a little bit. A full rewrite will be much more involved and should support production use-cases.

[domoritz]

The time to run the test went down from 23 to 13 seconds. Great work @blakeembrey.

However, with tsc and then running the tests over js, the tests take 7 seconds in total (of which the actual test running time is only 1.82 seconds).

[kirill-konshin]

@blakeembrey I confirm reduction from ~20 sec to ~10 sec in addition to baseline of separate tsc compile + test with v0.5.4.

[djeeg]

Hi @blakeembrey, thought I'd leave some stats from a project I have

"ts-node": "^0.5.5",

typescript files: about 80, ~1.25 MB

"startserver:dev": "./node_modules/.bin/ts-node --project \"./tsconfig-server.json\" \"./code/server/server.tsx\"",

starting server ...

• imports ...
  • done [1761ms]
• config ...
  • store ..
    ...
• listening ...
  • done
• done [28977ms]

ready on 3000

"startserver:dev:fast0": "@echo %time%",
"startserver:dev:fast1": "npm run build:server",
"startserver:dev:fast2": "if not exist \"output-server\" mkdir \"output-server\"",
"startserver:dev:fast3": "echo A | xcopy \"output\\ts\\tsconfig-server.json\" \"output-server\" /E",
"startserver:dev:fast4": "node \"output-server\\server\\server.js\"",
"startserver:dev:fast": "npm run startserver:dev:fast0 && npm run startserver:dev:fast1 && npm run startserver:dev:fast2 && npm run startserver:dev:fast3 && npm run startserver:dev:fast4",

@echo %time%
23:37:12.73
@echo %time%
23:37:22.06

starting server ...

• imports ...
  • done [659ms]
• config ...
  • store ..
    ...
• listening ...
  • done
• done [1377ms]

ready on 3000

I have trimmed a fair bit on the console output, just gives you an idea of the different between TSC

[blakeembrey]

Accepting PRs and any help, I'm not sure I have enough time to do any great optimisations to get much closer than tsc. The best optimisation, assuming we trust tsconfig.json, is to do what you're doing and compile and run it. It just breaks every dynamic loading use, which is the only places I currently use it anyway.

[blakeembrey]

I believe most of the performance issues have been optimised. I'm going to close this unless there's something actionable. I think the biggest improvement come from #129, but do let me know if it's not on par.

[djeeg]

@blakeembrey what you have done is epic!

upgrading from 0.5.5 to 1.0.0, I got a reduction of ~30s to ~20s
adding the --fast option gets it down to 2.3s
no idea how you did that, well done

now I just let the IDE do the types checks