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
fix(ivy): always re-analyze the program during incremental rebuilds (#33862)
Previously, the ngtsc compiler attempted to reuse analysis work from the
previous program during an incremental build. To do this, it had to prove
that the work was safe to reuse - that no changes made to the new program
would invalidate the previous analysis.
The implementation of this had a significant design flaw: if the previous
program had errors, the previous analysis would be missing significant
information, and the dependency graph extracted from it would not be
sufficient to determine which files should be re-analyzed to fill in the
gaps. This often meant that the build output after an error was resolved
would be wholly incorrect.
This commit switches ngtsc to take a simpler approach to incremental
rebuilds. Instead of attempting to reuse prior analysis work, the entire
program is re-analyzed with each compilation. This is actually not as
expensive as one might imagine - analysis is a fairly small part of overall
compilation time.
Based on the dependency graph extracted during this analysis, the compiler
then can make accurate decisions on whether to emit specific files. A new
suite of tests is added to validate behavior in the presence of source code
level errors.
This new approach is dramatically simpler than the previous algorithm, and
should always produce correct results for a semantically correct program.s
Fixes#32388Fixes#32214
PR Close#33862
Copy file name to clipboardExpand all lines: packages/compiler-cli/src/ngtsc/incremental/src/README.md
+20-14Lines changed: 20 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
This package contains logic related to incremental compilation in ngtsc.
4
4
5
-
In particular, it tracks metadata for`ts.SourceFile`s in between compilations, so the compiler can make intelligent decisions about when to skip certain operations and rely on previously analyzed data.
5
+
In particular, it tracks dependencies between`ts.SourceFile`s, so the compiler can make intelligent decisions about when it's safe to skip certain operations.
6
6
7
7
# How does incremental compilation work?
8
8
@@ -14,30 +14,36 @@ This information is leveraged in two major ways:
14
14
15
15
1) The previous `ts.Program` itself is used to create the next `ts.Program`, allowing TypeScript internally to leverage information from the previous compile in much the same way.
16
16
17
-
2) An `IncrementalState` instance is constructed from the previous compilation's `IncrementalState`and its`ts.Program`.
17
+
2) An `IncrementalState` instance is constructed from the old and new`ts.Program`s.
18
18
19
-
After this initialization, the `IncrementalState` contains the knowledge from the previous compilation which will be used to optimize the next one.
19
+
The compiler then proceeds normally, analyzing all of the Angular code within the program. As a part of this process, the compiler maps out all of the dependencies between files in the `IncrementalState`.
20
20
21
-
# What optimizations can be made?
21
+
# What optimizations are made?
22
22
23
-
Currently, ngtsc makes a decision to skip the emit of a file if it can prove that the contents of the file will not have changed. To prove this, two conditions must be true.
23
+
ngtsc makes a decision to skip the emit of a file if it can prove that the contents of the file will not have changed. To prove this, two conditions must be true.
24
24
25
25
* The input file itself must not have changed since the previous compilation.
26
26
27
-
*As a result of analyzing the file, no dependencies must exist where the output of compilation could vary depending on the contents of any other file.
27
+
*None of the files on which the input file is dependent have changed since the previous compilation.
28
28
29
-
The second condition is challenging, as Angular allows statically evaluated expressions in lots of contexts that could result in changes from file to file. For example, the `name` of an `@Pipe` could be a reference to a constant in a different file.
29
+
The second condition is challenging to prove, as Angular allows statically evaluated expressions in lots of contexts that could result in changes from file to file. For example, the `name` of an `@Pipe` could be a reference to a constant in a different file. As part of analyzing the program, the compiler keeps track of such dependencies in order to answer this question.
30
30
31
-
Therefore, only two types of files meet these conditions and can be optimized today:
32
-
33
-
* Files with no Angular decorated classes at all.
34
-
35
-
* Files with only `@Injectable`s.
31
+
The emit of a file is the most expensive part of TypeScript/Angular compilation, so skipping emits when they are not necessary is one of the most valuable things the compiler can do to improve incremental build performance.
36
32
37
33
# What optimizations are possible in the future?
38
34
39
35
There is plenty of room for improvement here, with diminishing returns for the work involved.
40
36
41
-
* The compiler could track the dependencies of each file being compiled, and know whether an `@Pipe` gets its name from a second file, for example. This is sufficient to skip the analysis and emit of more files when none of the dependencies have changed.
37
+
## Optimization of re-analysis
38
+
39
+
Currently, the compiler re-analyzes the entire `ts.Program` on each compilation. Under certain circumstances it may be possible for the compiler to reuse parts of the previous compilation's analysis rather than repeat the work, if it can be proven to be safe.
40
+
41
+
## Semantic dependency tracking
42
+
43
+
Currently the compiler tracks dependencies only at the file level, and will re-emit dependent files if they _may_ have been affected by a change. Often times a change though does _not_ require updates to dependent files.
44
+
45
+
For example, today a component's `NgModule` and all of the other components which consume that module's export scope are considered to depend on the component file itself. If the component's template changes, this triggers a re-emit of not only the component's file, but the entire chain of its NgModule and that module's export scope. This happens even though the template of a component _does not have any impact_ on any components which consume it - these other emits are deeply unnecessary.
46
+
47
+
In contrast, if the component's _selector_ changes, then all those dependent files do need to be updated since their `directiveDefs` might have changed.
42
48
43
-
* The compiler could also perform analysis on files which _have_ changed dependencies, and skip emit if the analysis indicates nothing has changed which would affect the file being emitted.
49
+
Currently the compiler does not distinguish these two cases, and conservatively always re-emits the entire NgModule chain. It would be possible to break the dependency graph down into finer-grained nodes and distinguish between updates that affect the component, vs updates that affect its dependents. This would be a huge win, but is exceedingly complex.
0 commit comments