一个速度提升 10 倍的 TypeScript
A 10x Faster TypeScript

原始链接: https://devblogs.microsoft.com/typescript/typescript-native-port/

TypeScript原生端口即将发布,将显著提升性能,解决大型代码库的可扩展性问题。新实现承诺将构建时间缩短10倍,加快编辑器启动速度,并降低内存使用率。初步基准测试显示,在各种项目中速度都有显著提升。 命令行类型检查器 (tsc) 预览版预计将于2025年中期发布,完整的项目构建和语言服务解决方案预计将于2025年底发布。原生端口将实现更快的错误列表显示、改进的重构功能,并支持先进的AI驱动开发者工具。 TypeScript 6 (JS版本) 将继续开发,并进行一些重大更改以与TypeScript 7 (原生版本) 保持一致。当前基于JS的代码库 (6.x) 将与原生版本 (7+) 并行维护,直到后者成熟。团队的目标是使两个版本高度一致,以简化升级过程。有关性能、新的编译器API和语言服务器协议 (LSP) 的详细信息即将公布。他们邀请大家在TypeScript社区Discord服务器上提供反馈和提出问题。

微软TypeScript团队正在发布一个用Go语言编写的TypeScript编译器(tsc)的全新原生实现,承诺构建速度提升10倍,并降低内存使用量。此举旨在通过大幅缩短编译时间和提高编辑器响应速度来增强开发者体验,尤其是在大型项目中。 TypeScript团队选择Go语言是因为其效率高、对内存布局的控制力强,并且其结构与现有的基于JavaScript的代码库相似,从而使移植过程更容易管理。他们提到C#的AOT能力还不成熟,或者在不同平台上的性能不一致。 团队承认这可能会影响现有工具和工作流程,并承诺在新的原生实现(7+)获得广泛采用之前,将继续维护当前的JavaScript代码库(6.x系列)。一个关键目标是创建一个可以集成到各种环境中的API。这一决定反映了对实用性和性能的关注,即使这意味着要放弃自托管编译器。

原文

Today I’m excited to announce the next steps we’re taking to radically improve TypeScript performance.

The core value proposition of TypeScript is an excellent developer experience. As your codebase grows, so does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases. Developers working in large projects can experience long load and check times, and have to choose between reasonable editor startup time or getting a complete view of their source code. We know developers love when they can rename variables with confidence, find all references to a particular function, easily navigate their codebase, and do all of those things without delay. New experiences powered by AI benefit from large windows of semantic information that need to be available with tighter latency constraints. We also want fast command-line builds to validate that your entire codebase is in good shape.

To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current codebase, we expect to be able to preview a native implementation of tsc capable of command-line typechecking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year.

You can build and run the Go code from our new working repo, which is offered under the same license as the existing TypeScript codebase. Check the README for instructions on how to build and run tsc and the language server, and to see a summary of what’s implemented so far. We’ll be posting regular updates as new functionality becomes available for testing.

How Much Faster?

Our native implementation is already capable of loading many popular TypeScript projects, including the TypeScript compiler itself. Here are times to run tsc on some popular codebases on GitHub of varying sizes:

Codebase Size (LOC) Current Native Speedup
VS Code 1,505,000 77.8s 7.5s 10.4x
Playwright 356,000 11.1s 1.1s 10.1x
TypeORM 270,000 17.5s 1.3s 13.5x
date-fns 104,000 6.5s 0.7s 9.5x
tRPC (server + client) 18,000 5.5s 0.6s 9.1x
rxjs (observable) 2,100 1.1s 0.1s 11.0x

While we’re not yet feature-complete, these numbers are representative of the order of magnitude performance improvement you’ll see checking most codebases.

We’re incredibly excited about the opportunities that this massive speed boost creates. Features that once seemed out of reach are now within grasp. This native port will be able to provide instant, comprehensive error listings across an entire project, support more advanced refactorings, and enable deeper insights that were previously too expensive to compute. This new foundation goes beyond today’s developer experience and will enable the next generation of AI tools to enhance development, powering new tools that will learn, adapt, and improve the coding experience.

Editor Speed

Most developer time is spent in editors, and it’s where performance is most important. We want editors to load large projects quickly, and respond quickly in all situations. Modern editors like Visual Studio and Visual Studio Code have excellent performance as long as the underlying language services are also fast. With our native implementation, we’ll be able to provide incredibly fast editor experiences.

Again using the Visual Studio Code codebase as a benchmark, the current time to load the entire project in the editor on a fast computer is about 9.6 seconds. This drops down to about 1.2 seconds with the native language service, an 8x improvement in project load time in editor scenarios. What this translates to is a faster working experience from the time you open your editor to your first keystroke in any TypeScript codebase. We expect all projects to see this level of improvement in load time.

Overall memory usage also appears to be roughly half of the current implementation, though we haven’t actively investigated optimizing this yet and expect to realize further improvements. Editor responsiveness for all language service operations (including completion lists, quick info, go to definition, and find all references) will also see significant speed gains. We’ll also be moving to the Language Server Protocol (LSP), a longstanding infrastructural work item to better align our implementation with other languages.

Versioning Roadmap

Our most recent TypeScript release was TypeScript 5.8, with TypeScript 5.9 coming soon. The JS-based codebase will continue development into the 6.x series, and TypeScript 6.0 will introduce some deprecations and breaking changes to align with the upcoming native codebase.

When the native codebase has reached sufficient parity with the current TypeScript, we’ll be releasing it as TypeScript 7.0. This is still in development and we’ll be announcing stability and feature milestones as they occur.

For the sake of clarity, we’ll refer to them simply as TypeScript 6 (JS) and TypeScript 7 (native), since this will be the nomenclature for the foreseeable future. You may also see us refer to “Strada” (the original TypeScript codename) and “Corsa” (the codename for this effort) in internal discussions or code comments.

While some projects may be able to switch to TypeScript 7 upon release, others may depend on certain API features, legacy configurations, or other constraints that necessitate using TypeScript 6. Recognizing TypeScript’s critical role in the JS development ecosystem, we’ll still be maintaining the JS codebase in the 6.x line until TypeScript 7+ reaches sufficient maturity and adoption.

Our long-term goal is to keep these versions as closely aligned as possible so that you can upgrade to TypeScript 7 as soon as it meets your requirements, or fall back to TypeScript 6 if necessary.

Next Steps

In the coming months we’ll be sharing more about this exciting effort, including deeper looks into performance, a new compiler API, LSP, and more. We’ve written up some FAQs on the GitHub repo to address some questions we expect you might have. We also invite you to join us for an AMA at the TypeScript Community Discord at 10 AM PDT | 5 PM UTC on March 13th.

A 10x performance improvement represents a massive leap in the TypeScript and JavaScript development experience, so we hope you are as enthusiastic as we are for this effort!

联系我们 contact @ memedata.com