TypeScript: 3.4.1 tsc works 20! times slower than 3.3.4

Catastrophic since new VsCode release which ship with 3.4.1 by default, It took me hours to figure out that 3.4.1 was the issue.

FYI, I’ve done some preliminary investigation, and the performance impact is caused by a large union of types (eg, the union of all possible jsx components) being pushed thru multiple layers of distributive conditionals with nested infer types (the constraints on the generics within @types/styled-components do this by pushing keyof JSX.IntrinsicElements thru React.ComponentPropsWithRef and then using it a bunch). The distribution has a multiplicative effect on work done. I’m still researching a performance fix in the compiler itself; however at least within @types/styled-components, I believe you can prevent the perf regression from triggering by removing PickU (using Pick instead), and explicitly writing a single distributive conditional around StyledComponentProps (rather than sprinkling extra distributions in everywhere).

Same here. I also got some significant performance hit in my front-end build (and I’m also using styled-components).

Autcomplete was so slow it was very hard to work on anything

Changing ts version for vs code helped.

I tried downgrading to @types/styled-components v4.1.10, but still see unbelievable slowdown on TS versions >= 3.4.0.

It’s a big project, with lots of dependencies so it’s hard to pinpoint what exactly is triggering it, but right now compilation is so slow that development is nearly impossible – 80 seconds for every compile, 75 secs in type checking. WebStorm can’t even recompile the code because of the timeouts. Fans are spinning like crazy on i7, 4x2 HT cores, 42 GB RAM, 4GB node heap iMac. I don’t think we can wait until 3.5.0 for the fix, it would just mean that we would just need to skip 3.4.0 entirely. Disabling strict function type checking is a very radical decision for a complex project.

Hey, anyone on the old version of @types/styled-components, based on my own testing, it seems like #30637 actually is what fixed this on master - meaning the current typescript@next already contains a fix. Would love some feedback on if that’s true for your projects which are more complex than a just-initialized CRA template. But in other, more important news: #30637 is a breaking change (though we don’t think it should actually unduly affect anyone unless it’s pointing out real bugs!), meaning we will not be backporting it to 3.4 (😲), at least as-is. So if your @types/styled-components version is locked to the version with bad perf in 3.4, you’ll want to try to use the TS nightly, at least for now. Likewise, if your TS is locked to 3.4, you’ll want to either downgrade to an older version of @types/styled-components, or upgrade to a newer version of @types/styled-components that was pushed today that has the types which triggered bad perf on 3.4 removed.

typescript-bot (TypeScript Bot) 2 minutes ago I just published @types/styled-components@4.1.13 to npm.

– https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499#issuecomment-480225465

I have investigated this with TypeScript 3.4.1, and the issue does not show up (for me) with @types/styled-components v4.1.10, but does happen with @types/styled-components v4.1.11. The change between these two versions is related to distributing over union types. Perhaps this helps figure it out.

Same ~x2 time slowdown for me too:

typescript@3.3.4000 and @types/styled-components@4.1.14: ~8.80s. typescript@3.4.2 and @types/styled-components@4.1.14: ~18.01s typescript@next and @types/styled-components@4.1.14: ~15.40s.

@weswigham Should we reopen this issue or open another one?

@cbdeveloper @qmcree The main fix should be released in 3.5, you can try the next tag for now to see if it works better.

That’s the one I tested on and it was a huge improvement.

Although performance was improved in the newer versions, there is still a significant slowdown running tsc. Benchmarks:

typescript@3.4.2 and @types/styled-components@4.1.14: ~7.5 seconds typescript@3.3.4000 and @types/styled-components@4.1.12: ~3 seconds

I am using typescript@3.5.0-dev.20190512

tsc --noEmit

Still a memory leak and crash.

Yesterday, without looking for the issue in this repo, I opened this issue in @types/styled-components https://github.com/DefinitelyTyped/DefinitelyTyped/issues/34391.

@michsa saw that the performance change was done between the builds typescript@3.4.0-dev.20190223 (working normally) and 3.4.0-dev.20190226 (taking a long time)

Maybe it’s worth to cross the info on both threads to find down the root of this issue.

Actually I just figured it out. My VS Code workspace was still using 3.4.5. Changing the workspace to use 3.5.1 fixed the problem.

I think https://github.com/Microsoft/TypeScript/issues/30819 should already cover the lesser perf regression.

@weswigham Will the perf fix be included in the next release?

3.5, yes. 3.4 series, no. #30637 isn’t a bugfix level change, even though it does fix this - it has other major typesystem effects which we’re not comfortable publishing as a patch.

That’s really unfortunate. The fix likely responsible for the performance regression was applied before 3.4 was released. We couldn’t detect major performance regressions so it seemed fine.

The same fix was also applied to react-router (withRouter), @emotion/styled and @material-ui/core@next (withStyles). Can somebody who uses those packages confirm if 3.4.1 has the same performance issues with those packages?

I am also experiencing a significant slow-down after upgrading TypeScript from 3.3.4000 to 3.4.1. As a result, live IDE type checking is almost inoperable. Also have styled-components@4.2.0 and @types/styled-components@4.1.12 installed.

@jewseppi can you get better performance with typescript@next?

I tried typescript@next which pulled down typescript@3.5.0-dev.20190509 and this does resolve the performance issue. Guess we’ll wait for the 3.5 release before we upgrade TypeScript.

EDIT: Installing @types/styled-component didn’t solve my problem. But I downgraded VSCode from 1.33 to 1.32 and now it’s fixed.

I was having problem with slow intellisense on VScode on my JS (React) project. I am also using styled-components v^4.1.3.

Not sure if this is going to help, but I can confirm that all issues are now fixed, since I’ve installed @types/styled-components v^4.1.14 (I installed the latest). The intellisense now is perfectly responsive and very fast. I don’t have typescript installed globally or locally.

Not sure, but I think this issue began when updated to VScode 1.33. Auto-updates are on, though, and as it slowly started to bother me, it might have been happening since an earlier version, but not too long ago.

Version:          Code 1.33.0 (0dd516dd412d42323fc3464531b1c715d51c4c1a, 2019-04-04T15:14:28.026Z)
OS Version:       Windows_NT x64 10.0.17763
CPUs:             Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz (4 x 3000)
Memory (System):  7.96GB (2.88GB free)
VM:               0%
Screen Reader:    no
Process Argv:
GPU Status:       2d_canvas:                    enabled
                  checker_imaging:              disabled_off
                  flash_3d:                     enabled
                  flash_stage3d:                enabled
                  flash_stage3d_baseline:       enabled
                  gpu_compositing:              enabled
                  multiple_raster_threads:      enabled_on
                  native_gpu_memory_buffers:    disabled_software
                  rasterization:                enabled
                  surface_synchronization:      enabled_on
                  video_decode:                 enabled
                  webgl:                        enabled
                  webgl2:                       enabled

CPU %   Mem MB     PID  Process
    2       84   10412  code main
    0       66    4036     shared-process
    3       97   15368     gpu-process
    0      187   16180     window (undefined)
    3      247   17476     window (ΓùÅ AddProductPage.js - myProject - Visual Studio Code)
    0        9    6456       winpty-process
    0       72    4176         C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
    0        8   13552           C:\WINDOWS\system32\cmd.exe /c ""C:\Users\MAINUSER\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd" --status"
    0       36   15276             electron_node cli.js
    1       56   17520               "C:\Users\MAINUSER\AppData\Local\Programs\Microsoft VS Code\Code.exe" --status
    0       13    6220         console-window-host (Windows internal process)
    0       11    6828       watcherService
    0       14    6896         console-window-host (Windows internal process)
    0       15   13864       electron-crash-reporter
    0       94   16468       extensionHost
    0      214    6792         electron_node tsserver.js
    0       47   15296           electron_node typingsInstaller.js typesMap.js
    0       35   12680         "C:\Users\MAINUSER\AppData\Local\Programs\Microsoft VS Code\Code.exe" "c:\Users\MAINUSER\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\json-language-features\server\dist\jsonServerMain" --node-ipc --clientProcessId=16468    0       65   14308         electron_node eslintServer.js

Workspace Stats:
|  Window (ΓùÅ AddProductPage.js - myProject - Visual Studio Code)
|    Folder (myProject): 190 files
|      File types: js(158) json(9) otf(4) png(3) html(3) ico(2) gitignore(2)
|                  rules(2) css(2) editorconfig(1)
|      Conf files: package.json(2) jsconfig.json(1)

@weswigham I checked out next and it seems like it significantly sped up the build times (1.67 mins to 9.72s). Maybe some others can chime in with their results too?

@fabb: May 2019, as per roadmap.