Ngtsc much speed such fast #34332

To create a binding parser, an instance of `ElementSchemaRegistry` is required. Prior to this change, each time a new binding parser was created a new instance of `DomElementSchemaRegistry` would be instantiated. This is an expensive operation that takes roughly 1ms per instantiation, so it is key that multiple allocations are avoided. By sharing a single `DomElementSchemaRegistry`, we avoid two such allocations, i.e. save ~2ms, per component template.

The export scope of NgModules from external compilations units, as present in .d.ts declarations, does not change during a compilation so can be easily shared. There was already a cache but the computed export scope was not actually stored there. This commit fixes that.

During TypeScript module resolution, a lot of filesystem requests are done. This is quite an expensive operation, so a module resolution cache can be used to speed up the process significantly. This commit lets the Ivy compiler perform all module resolution with a module resolution cache. Note that the module resolution behavior can be changed with a custom compiler host, in which case that custom host implementation is responsible for caching. In the case of the Angular CLI a custom compiler host with proper module resolution caching is already in place, so the CLI already has this optimization.

On a large compilation unit with big templates, the total time spent in the `PlainCharacterCursor` constructor was 470ms. This commit applies two optimizations to reduce this time: 1. Avoid the object spread operator within the constructor, as the generated `__assign` helper in the emitted UMD bundle (ES5) does not optimize well compared to a hardcoded object literal. This results in a significant performance improvement. Because of the straight-forward object literal, the VM is now much better able to optimize the memory allocations which makes a significant difference as the `PlainCharacterCursor` constructor is called in tight loops. 2. Reduce the number of `CharacterCursor` clones. Although cloning itself is now much faster because of the optimization above, several clone operations were not necessary. Combined, these changes reduce the total time spent in the `PlainCharacterCursor` constructor to just 10ms.

The template parser has a certain interpolation config associated with it and builds a regular expression each time it needs to extract the interpolations from an input string. Since the interpolation config is typically the default of `{{` and `}}`, the regular expression doesn't have to be recreated each time. Therefore, this commit creates only a single regular expression instance that is used for the default configuration. In a large compilation unit with big templates, computing the regular expression took circa 275ms. This change reduces this to effectively zero.

Avoids the usage of array destructuring, as it introduces calls to a `__values` helper function in ES5 that has a relatively high performance impact. This shaves off roughly 130ms of CPU time for a large compilation with big templates that uses i18n.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ngtsc much speed such fast #34332

Ngtsc much speed such fast #34332

Commits on Dec 12, 2019