Default watch options not working as expected — steady-state CPU usage

[srmagura]

Bug Report

🔎 Search Terms

watch, watchOptions, TSC_WATCHFILE

🕗 Version & Regression Information

I don't think this is a new issue. The behavior is the same between the latest official release (4.4.3) and the latest dev release (4.5.0-dev.20210926).

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about watchOptions

⏯ Playground Link

N/A

💻 Code

Tested on a medium TypeScript codebase that contains ~1110 TypeScript files and an average amount of node_modules.

🙁 Actual behavior

This issue concerns steady-state CPU usage when running tsc --watch. When I say "steady-state", I mean the CPU usage after the initial compilation is done and TypeScript is just watching files, none of which are changing.

Case 1

TSC_WATCHFILE environment variable not set. tsconfig.json has

"watchOptions": {
    "fallbackPolling": "dynamicPriority"
}

Steady-state CPU usage: ~6.5%

Case 2

TSC_WATCHFILE environment variable not set. tsconfig.json has

"watchOptions": {
    "watchFile": "useFsEvents",
    "watchDirectory": "useFsEvents",
    "fallbackPolling": "dynamicPriority"
}

Steady-state CPU usage: ~0.1%

Case 3

TSC_WATCHFILE = UseFsEventsWithFallbackDynamicPolling. No watchOptions in tsconfig.json.

Steady-state CPU usage: ~0.1%

🙂 Expected behavior

According to the TypeScript 3.8 release notes, the defaults for watchFile and watchDirectory are useFsEvents. Unless these defaults were changed in a later TypeScript version, my "Case 1" and "Case 2" should have exhibited the same CPU usage.

It makes sense that "Case 2" and "Case 3" had the same CPU usage, since the environment variable is just a different way of setting the same options.

Overall, the desired behavior is that tsc --watch uses as little CPU as possible while still doing a good job of watching files using the default watchOptions.

🔗 Related links

• TypeScript Handbook: Configuring Watch
• 2019 Johnny Reilly blog post on TSC_WATCHFILE
• 2019 issue posted by Johnny Reilly about watch performance

💻 Test environment

Windows 10
Node 14.17.6
AMD Ryzen 5 2600 Six-Core Processor
PowerShell 7.1.4

[andrewbranch]

@amcasey know anything about this?

[amcasey]

@andrewbranch I manage to misspeak every time I speculate about file watchers. 😉

It seems reasonably clear that Case 1 is using polling, but I have no idea whether that's by design - I don't know either the default or whether heuristics are used to adapt to the environment (though I would certainly expect FS events to be used on Windows without an explicit override).

[sheetalkamat]

Watch file is default to polling for correctness .. so your case 1 and 2 are not same ..

[srmagura]

Okay, so it's just that the TS 3.8 release notes were wrong?

I do wonder if FS events would be a better default than polling but that's up to you all.

[taxilian]

I'd really love to see fsevents become the default -- I'd rather have it occasionally recompile on an event that probably didn't require it than use -- consistently -- 27-35% of one of my CPUs on my intel macbook pro 16". It is almost as bad on my 2021 14" mbp apple silicon. It kills my battery life, and I only today discovered this.

Just putting out some additional information so you know it's still affecting users; either more visibility on the option or a more intelligent way to prevent it from killing system performance would be really neat.

[sheetalkamat]

Option 1 and options 2 are not same since option1 uses polling for file watching which will be cpu intensive