Repository navigation
Compile times inconsistent with module dependents count? #8479
Description
$ tsc --version
Version 1.9.0-dev.20160505
$ node --version
v5.10.1 # in case it's relevant to this discussion{
"compilerOptions": {
"declaration": false,
"jsx": "react",
"module": "system",
"newLine": "LF",
"noEmitOnError": true,
"noImplicitAny": true,
"noImplicitReturns": true,
"noLib": true,
"removeComments": false,
"rootDir": ".",
"sourceMap": true,
"target": "es5"
}
}
We have a relatively modest ~210k lines of code/type definitions etc in our application.
Some of our core files are import-ed by many files (e.g. a core utility library). i.e. there are many dependents on such modules. Let's call this Group 1.
Other files, e.g. tests, are never import-ed by any other files. i.e. there are zero dependents on such modules. Let's call this Group 2.
We use tsc --watch to recompile when any of the files as referenced by tsconfig.json are modified.
The bizarre thing is that compile times are relatively constant, regardless of whether a file modification happens to a file from Group 1 or Group 2. In the following relatively unscientific tests, I simply touch-ed a file from the named group, i.e. bumped it's modification time, and observed the time stamps output from tsc --watch:
# e.g.
6:59:04 PM - File change detected. Starting incremental compilation...
6:59:12 PM - Compilation complete. Watching for file changes.
- Group 1: > 100 dependents: ~7-11 secs
- Group 2: 0 dependents: ~7-11 secs
Let's ignore the fact for a second there is a wide range of compile times
This doesn't seem to make much sense (but then I know very little about the compiler!) because Group 2 files have zero dependents.
Gut instinct would tell me that the re-compile times when changes are limited to a single Group 2 file should be an order of magnitude lower.
Can someone either correct this false expectation or chime in here?
Clearly we, like others, would love to see compile times fall as much as possible because it makes the development lifecycle that much more pleasant so I'd be more than willing to help debug/provide analysis on the above observation.
Thanks
Activity
mhegazy commentedon May 5, 2016
There is no optimization in place for modules in
tsc --watchor CompileOnSave in VS. when a file is changed a recompilation is triggered, and that builds all output.Adding the optimization is tracked by #3204
myitcv commentedon May 5, 2016
Thanks - that answers it.
myitcv commentedon Oct 3, 2016
Mohamed Hegazy (@mhegazy) you mentioned that optimisation of the kind referenced above should be covered in #3204. In a recent update to #3204 you mention 'this' is covered in #9837.
Please can you help point out what changes are required in order to optimise
tsc --watchgiven the changes in #9837?As of
2.1.0-dev.20161003I'm not seeing any difference in compile times between the two categories referenced above.Thanks
mhegazy commentedon Oct 3, 2016
Sorry for the confusion. we have two features that do more or less the same thing in different contexts,
--wwhich is mainly fortsconnode, and Compile on Save in IDE's. we have recently updated compile-on-save to use a new optimized builder that tells it what to build when a file changed (see #9837). we need to port the--watchimplementation to run on top of that, this is covered by #10879.the proposal in #3204 was for a specific use case, the implementation in #9837 covered this and adds a new set of optimizations as well.
myitcv commentedon Oct 4, 2016
Thanks for the link to #10879 - that looks like it covers things