[microsoft/TypeScript] Performance Enhancement Opportunities: Advanced Caching and Memory Optimization (Issue #62543)
DRANK

jdmiranda created an issue (microsoft/TypeScript#62543) ## Summary This issue proposes several concrete performance optimization opportunities for the TypeScript compiler, building upon the excellent existing work in module resolution caching, incremental compilation, and the upcoming native compiler port. These suggestions focus on extending caching mechanisms and memory optimization techniques that could provide significant performance improvements for large-scale projects. ## Context While TypeScript has made tremendous progress in performance (particularly with the upcoming 10x native compiler improvements announced in 2025), there remain opportunities for optimization in the current compiler architecture. Our team has been exploring performance enhancements in module resolution caching, achieving **1.1M+ module resolutions per second** through aggressive caching strategies, and we've identified several complementary optimization areas worth considering. ## Proposed Optimization Areas ### 1. Type Checking Result Cache (Beyond Module Resolution) **Current State**: The compiler currently caches module resolution results, assignability checks, identity checks, and subtype checks (visible via `--extendedDiagnostics`). **Opportunity**: Extend caching to cover additional type checking operations: - **Type inference results cache**: Cache the results of complex type inference operations, particularly for: - Generic type instantiations (currently recreated on each use) - Conditional type resolutions - Mapped type transformations - **Type relation cache**: Extend beyond assignability to cache structural type comparisons - **Import type resolution cache**: Cache resolved types from `import()` type expressions **Expected Impact**: For projects with heavy generic type usage, this could reduce type checking time by 15-30% based on similar caching strategies in other compilers. **Reference**: Related to existing work in PR #37055 (module resolution cache optimization) --- ### 2. Symbol Table Optimization **Current State**: The compiler creates symbol tables during the binding phase using HashMap structures. **Opportunity**: Optimize symbol table memory usage and access patterns: - **Symbol interning**: Deduplicate common symbol properties across the codebase (similar to string interning) - Property names - Common type signatures - Frequently used identifiers - **Hierarchical symbol caching**: Cache parent-child symbol relationships to avoid repeated lookups - **Symbol table compression**: For large projects, compress infrequently accessed symbol metadata **Expected Impact**: Memory reduction of 10-20% in symbol table storage, with potential access time improvements of 5-10%. **Reference**: Builds on the monomorphic AST nodes work (#59198) --- ### 3. Source File Caching Improvements **Current State**: The compiler caches `ts.SourceFile` objects in watch mode and incremental builds. **Opportunity**: Enhance source file caching with: - **Partial source file updates**: Instead of re-parsing entire files, implement incremental parsing for localized changes - Track AST node boundaries and only re-parse affected sections - Use change tracking similar to LSP's `textDocument/didChange` - **Lazy AST materialization**: Parse on-demand rather than eagerly parsing all files - Parse imports/exports first for dependency graph - Delay full parsing until type checking is needed - **Compressed AST storage**: For infrequently accessed files, store compressed AST representations **Expected Impact**: For watch mode scenarios, could reduce re-compilation time by 20-40% when only small portions of files change. **Reference**: Extends the incremental compilation work from TypeScript 3.4 --- ### 4. Incremental Compilation Enhancements **Current State**: `.tsbuildinfo` files store project graph information for incremental builds. **Opportunity**: Expand incremental compilation granularity: - **Function-level change detection**: Track changes at function/method granularity rather than file-level - Only re-check types for changed functions and their dependents - Store function-level signatures in `.tsbuildinfo` - **Cross-file dependency pruning**: More precisely track which files are affected by changes - Build fine-grained dependency graphs (e.g., "function A uses type B from module C") - Avoid unnecessary re-checking of unaffected code paths - **Parallel type checking with finer granularity**: Enable parallel checking of independent functions within the same file **Expected Impact**: For large projects with localized changes, reduce incremental build times by 30-50%. **Reference**: Builds on project references and existing incremental compilation --- ### 5. Diagnostic Message Pooling **Current State**: Diagnostic messages are created individually for each occurrence. **Opportunity**: Implement object pooling for diagnostic messages: - **Message template reuse**: Pre-allocate and reuse diagnostic message objects - **Diagnostic deduplication**: Identify and consolidate duplicate diagnostics before reporting - **Lazy diagnostic formatting**: Defer string formatting until diagnostics are actually consumed **Expected Impact**: Reduce memory allocation pressure by 5-15% in projects with many diagnostics, with minor speed improvements from reduced GC pressure. **Similar pattern**: Used successfully in Babel and ESLint --- ### 6. Declaration Emit Optimization **Current State**: Declaration file generation happens after type checking. **Opportunity**: Optimize declaration emit performance: - **Incremental declaration emit**: Only regenerate declarations for changed files and their dependents - Store declaration dependencies in `.tsbuildinfo` - Skip unchanged declaration files entirely - **Declaration template caching**: Cache common declaration patterns (e.g., interface declarations, type aliases) - **Parallel declaration emit**: Generate declarations in parallel across multiple files **Expected Impact**: For projects with `composite: true`, reduce declaration emit time by 25-40%. **Reference**: Complements project references architecture --- ## Implementation Considerations ### Backward Compatibility All proposed optimizations should: - Maintain full semantic compatibility with existing TypeScript behavior - Be transparent to end users (no API changes required) - Work with existing compiler flags and configurations ### Measurement & Validation - Benchmark against real-world large projects (e.g., VS Code, TypeScript itself, large monorepos) - Use `--extendedDiagnostics` and `--generateTrace` to measure improvements - Track memory usage alongside speed improvements ### Phased Rollout These optimizations could be implemented incrementally: 1. **Phase 1**: Type checking result cache + Symbol interning (lowest risk, high impact) 2. **Phase 2**: Source file caching improvements + Diagnostic pooling 3. **Phase 3**: Fine-grained incremental compilation + Declaration emit optimization ## Our Contribution We've implemented module resolution caching optimizations in our fork that achieve **1.1M+ module resolutions per second** (compared to ~100K/sec baseline) through: - Aggressive LRU caching with configurable size limits - Pre-warming caches with common node_modules paths - Optimized cache key generation We'd be happy to: - Share detailed benchmarks and implementation approaches - Collaborate on integrating similar optimizations into the official compiler - Contribute PRs for any of the proposed enhancements - Provide test cases from our large-scale projects ## Related Issues & Work - #40356 - Module resolution cache improvements - #37055 - Module resolution cache for watch and editor - #59198 - Monomorphic AST nodes - #44305 - Incremental build performance - TypeScript 3.4 - Incremental compilation - 2025 Native Compiler Initiative - 10x performance improvements ## References - [TypeScript Performance Wiki](https://github.com/microsoft/TypeScript/wiki/Performance) - [Performance Tracing Documentation](https://github.com/microsoft/TypeScript/wiki/Performance-Tracing) - [Compiler Notes - Glossary](https://github.com/microsoft/TypeScript-Compiler-Notes/blob/main/GLOSSARY.md) --- We believe these optimizations could meaningfully improve developer experience, especially for large-scale TypeScript projects, and we're excited to collaborate with the TypeScript team on making the compiler even faster. Thank you for considering these suggestions! cc: @RyanCavanaugh @DanielRosenwasser @sandersn (tagging TypeScript team members - please feel free to redirect as appropriate) -- Reply to this email directly or view it on GitHub: https://github.com/microsoft/TypeScript/issues/62543 You are receiving this because you are subscribed to this thread. Message ID: <microsoft/TypeScript/issues/62543@github.com>

github.com
Related Topics: TypeScript