Performance issue with the declaration bundling

[archfz]

• Version: 2.0.5
• Rollup Version: 2.70.1

I really like this plugin. I have tried all the other available options and only this one generates correct and proper declaration type bundle (with namespaces). Good job with that. The issue is that while this is true, the cost is a really high performance hit, that is affecting development.

The project I work on is private, so I cannot share reproduction code. There are like 3000~ lines of code, which is not that much to be honest. Compilation is configured with typescript incremental builds. The performance goes something like this:

• With declaration emit enabled: init 15s, on change 11s
• With declaration emit disabled: init 6s, on change 1.1s

The on change metric is when changes are done in development. So we see an almost 10x slowdown, which is hurting development a lot. Now I have tried other compilers like rollup-plugin-typescript2 and with declaration enabled still can get 2.5s on change. So let's say more accurately a slowdown of around 5x.

Would it be possible to do any improvements on this performance?

[wessberg]

Hi there. Thanks for reaching out.

The declaration bundling phase is built on a foundation that at its core can be very efficient, as it is built as a series of Custom Transformers and as such directly integrate with TypeScript's incremental builder programs. However, it is quite complex in its implementation, as it goes beyond what other tools are doing and applies tree-shaking and code-splitting at the declaration level, and these processes add a lot of computational overhead. Specifically, it is implemented as a series of visitor functions, each of which perform a lot of work that has to be executed serially. There are most likely a lot of micro- and macro optimizations that can be applied here and there to speed up the work on the declarations, including more aggressive caching and possibly earlier returns here and there. Maybe some of these steps can be combined and run in parallel. I'm absolutely confident there's a lot of things that can be done here, however I think this is something that can improve iteratively over time. For now, I'm going to mark your issue as a feature request, and when I have the time I'll look into potential areas for improving declaration bundling performance.

[archfz]

I am thinking as a first step to identify slower parts, and potentially expose configs to disabled these parts. Like for example maybe tree shaking is not needed for everyone. But ofc what can or cannot and worth disabling is dependent on findings on first part.

[wessberg]

The gains from disabling tree-shaking are quite often actually negative, since that will cause later steps to have to actually traverse way more nodes than necessary. In a way, the tree-shaking is one form of optimization, as we can ignore a lot of nodes when we deconfliict their identifiers and such. As it is, there are no other steps that can be considered optional, as all of them are required to produce correct declarations.