Slow testing

[xogeny]

I'm seeing an issue with mocha, ts-node and typescript. My current versions are 3.0.2, 1.3.0 and 2.0.0, respectively. However, I've been having this issue for a while with older versions of these tools, so this isn't new to, for example, typescript@2.0.0 or mocha@3.0.2.

To see the issue, consider the following three commands:

$ time tsc                                                                                                                                     

real    0m4.380s

$ time mocha lib/test/ConsistencyTests.js                                                                                                      
...                                                                                                                                     
real    0m3.487s  

So far, so good. But this shows the real issue:

$ time mocha test/ConsistencyTests.ts       
...
real    1m22.379s         

In summary, it takes over 10x longer to run mocha and have ts-node do the compilation behind the scenes than to run tsc and then mocha on the emitted code. Am I missing something here?

My mocha.opts file is pretty standard, I think:

--compilers ts:ts-node/register
--harmony
--harmony_destructuring
--harmony-proxies

Note, it doesn't seem like the "harmony" stuff is (entirely?) to blame. If I remove those flags, it takes over 28 seconds before I even get an error back related to destructuring syntax. So something is going on during that time that is way out of proportion with the normal time it takes to compile the code

I should add that this is on Windows (related to #163 or #137 ?).

Any suggestions? Anything I can do to further diagnose the problem. This is my customer's proprietary code, so no chance to share a reproducible case I'm afraid.

[xogeny]

I should add that if I use mocha --watch, the subsequent tests (after the first), are reasonable. So this has something to do with startup.

[blakeembrey]

That sounds painful. What happens when you run in --fast (E.g. just transpiling)?

[xogeny]

I'm not running ts-node directly, I'm just using it for mocha. How can I configure it to use the --fast flag in that case? I looked through the docs and I didn't see anything except the environment variable TS_NODE_FAST. I tried setting that to true, but it didn't seem to have any impact. Is there something else I should try?

[blakeembrey]

Nope, that would have worked. There's not a lot else I can recommend sadly. If you do manage to find out the cause, please let me know. It does seem related to #163.

[xogeny]

Is there any (easy) way to determine what it is spending it's time on? The tsc compliation is so much faster by comparison, it seems like there must be something else going on here.

[xogeny]

I looked at #163. I instrumented the ts-node code to report every file it calls service.getEmitOutput for. Each call is quite slow (seems 100s of milliseconds per file). So it does seem related. I haven't checked, but I suppose the same synchronizeHostData issue is at work here. Unfortunately, I don't have reproducible case I can share with @mhegazy.

I'm wondering if there is some kind of Windows service that is seeing this activity and somehow confusing things by writing something to the file system causing it to think a sync is required each time. Not sure how to figure that out though. I'll try to keep digging.

[xogeny]

OK, I'm not sure what I did, but I think I resolved it. It might have been some kind of interaction between locally installed vs globally installed modules. I'm not really sure. I was just trying new stuff (TS2.0.0, Mocha 3.x) and it went away and now I can't get it back (good riddance). Who knows, perhaps if there was a gremlin somewhere in the system triggering unwanted syncs it will return. But for now, I can't even seem to trigger the issue. For the record, I'm (now) using node 4.5.0, typescript@2.0.0, ts-node@1.3.0 and mocha@3.0.2.

[andreykaipov]

I was having similar issues until I created a tsconfig.json file from the directory I was running Mocha from. Interestingly enough, even a completely empty tsconfig.json drops the time significantly!

Without a tsconfig.json --

$ time mocha -r ts-node/register ./**/*.spec.ts
...
real    0m36.181s

With an empty tsconfig.json --

$ time mocha -r ts-node/register ./**/*.spec.ts
...
real    0m3.213s

Hope this helps somebody from the future!

[blakeembrey]

I'd definitely recommend having a local tsconfig.json file. Without it, we'd resolve upward to try and find one. There may possibly be some other issues with TypeScript looking up all the node_modules directories for types too. I'd be happy to try and improve the situation if anyone wants to submit PRs also - we could make it so that a tsconfig.json or path to one is always required.

[andreykaipov]

@blakeembrey Ah yes you're right! I saw your code here from the tsconfig module that resolves upward for a tsconfig.json, but that wouldn't add too much time, right? As for requiring a tsconfig.json file, I don't think it should be required. With one file but no local tsconfig.json file, even the TypeScript compiler is super slow, so it's probably like you mentioned with the compiler trying to look into all of the node_modules directories if it can't find a local tsconfig.json.