Type checking/VS Code slow when using MUI

TypeScript Version: 3.8.0-dev.20191029

Search Terms: mui, material-ui, typescript, slow

Example Project
https://github.com/jdoklovic/mui-slowness

Expected behavior: Make a bad change to something in src/react/pages/Main.tsx autocomplete seems to be speedy, and error reporting should be too.

Actual behavior: Takes forever to see errors

Related Issues: #32085, #32229, #31817, #30908

Not exactly sure what's going on, but the error reporting in VS Code is super slow.
I've made sure I'm using specific named imports, and I've even forked MUI and mad all of the internal code so the same and removed things like import from '..' but it didn't seem to help.

Here's the output from tsserver logs which doesn't seem to contain anything that jumps out at me.
Also note, I'm using typescript-eslint with the VS Code ESLint extension, not tslint, but eslint seems to be pretty fast.

mui-slowness-tsserver.log

First off, this bug report is just about perfect, so thanks for that! Second, skipLibCheck usually helps, but you've already got that. Anyone else reading this might want to give that a shot.

I'll look for possible improvements in both TS and the MUI type decls. Thanks!

Andrew Casey (@amcasey)

Thanks Andrew Casey (@amcasey). Let me know if you need any other data/log dumps or whatever.
Also, I hsould mention that if I launch the app with webpack-dev-server --open --config webpack.react.webview.js the VS Code editor is still super slow to report errors, but if I make a change and save, the watch process/compilation is super fast and usually completes and reloads the browser before VS Code catches up. Not sure if that's useful info or not.

The issue we usually see with responsiveness in MUI consumers is with the large number of icon types. In this case, however, it appears that MUI is using some complicated conditional types to provide sophisticated checking of API usage. I'm experimenting with both tweaking their types and improving compiler perf, but, so far, the solution isn't obvious.

It's not just errors... Any changes takes enormous time to be processed.

I am in compilation hell. 300% CPU and my machine is bricked for 15 minutes.

"@material-ui/core": "^4.3.3",
"@material-ui/icons": "^4.2.1",
"@material-ui/pickers": "^3.2.4",
"@material-ui/styles": "^4.3.3",

"typescript": "^3.7.2",

TSC is still incredibly, frustratingly slow for me in any files using MUI. Typically takes anywhere between 5 to 10 seconds from making a change to the type checking to finish and errors being flagged.

When I first open VSC and start the build process, it seems sometimes type checking is relatively fast (1-2 seconds), but becomes slower over time (eventually hitting 5-10 secs). Other times, however, it seems it's also the amount of MUI components used in the working file that impacts TSC speeds.

I remember about 5 months ago I found using specifically TypeScript version 3.3.4000 to actually resolve the slow TSC issues, whereas the following versions were all affected by this slowness. Not tested it since though.

In a small project of mine, I've started to have a watch process with noEmit specifically for *.tsx files. This gives significantly faster feedback (4-5 seconds) if something broke than IntelliSense, which takes forever to update.

Unfortunately, I have yet to find either a solution or a mitigation. I'm reluctant to push a totally new strategy onto the MUI type authors and finding a smaller change with the same effect is much more difficult. Obviously, you do have the option of not using @types/material-ui, but that will make completion a lot less useful and error detection a lot less thorough.

Ragnar Rebase (@rrebase)

Ragnar Rebase (@rrebase) Ravnurin AlCalzone Having additional (ideally, small) repros would help with this one. Is your code shareable?

Brainicorn (@jdoklovic)

I decided to start over with a clean version of Brainicorn (@jdoklovic)'s repro and now I'm seeing a ~3 second delay on startup and then good responsiveness after that (there's a ~2 second lag for squiggles, but that's by design, so they don't flicker, etc). I'm on VS Code 1.40.2 and TS 2.8.0-dev.20191207. I'll try to figure out where those 3 seconds are going, but they're a lot less worrisome than the 12 seconds in the original report.

If people are still seeing longer delays, additional repros would be very helpful. Also, consider giving TS 3.7 a shot, since we made a bunch of perf fixes.

Is your code shareable?

I can email you an archive with the repo in it if that is okay. It currently consists of about 23 TSX and 32 TS files that are relevant to the frontend where I'm seeing the delays. I'll see if I can reduce the size or at least give you some steps how to trigger the longer delays.

I think that the holistic performance issue should be tracked on the MUI repo because TS just doesn't have the domain expertise to evaluate the correctness vs performance trade-offs for MUI developers; BUT specific issues should be filed here, including but not limited to:

Yep, I think this sums this up perfectly and concise. Ultimately we would have two versions we could publish: strict but slow and slow but fast. And then see what people prefer and which leads to better software.

Basically implement what tsconfig can do with its various strict configs at a library level.

Though this is ultimately a very hard and expensive task (for a developer). The main issue is that publishing looser types would almost never cause any failures because most users already have a passing typecheck. So we couldn't really rely on immediate community feedback. The library is usually the only location where both passing and failing typechecking is tested.

That's why I was saying that it would be really nice if somebody would spend some time by increasing performance and checking how much of our type test would started failing (considering we also assert on type-checking failures). Our type test suite is fairly extensive by now so I would hope it would help in tackling this issue. So far I've only seen analysis looking at performance improvements but not analysis looking at strictness/soundness.

So we will continue to track this inhttps://github.com/mui/material-ui/issues/19113. We still care about it (otherwise the issue wouldn't be open).

Ultimately we would have two versions we could publish

I love the idea of testing them side-by-side, but note that TypeScript doesn't (and won't soon) have a convenient way to associate more than one set of type definitions with a given import. At present, if you import a package and it has typings, they'll be used unconditionally (I'd love to know if someone has found a loophole that doesn't involve manipulating files under node_modules).

So we couldn't really rely on immediate community feedback

I'm not sure I understand your statement clearly, but I think we'll hear about it pretty quickly if people start getting a lot of runtime errors that the tooling should have caught.

So we will continue to track this inhttps://github.com/mui/material-ui/issues/19113. We still care about it (otherwise the issue wouldn't be open).

❤️

I came here through a Reddit post about Intellisense and MUI, and although it's not totally relevant to getting solutions, I wanted to say hats off to everyone here who's been working so hard and for so long to tackle this problem. When people have been earnestly struggling together for over two years to make things better for everyone out there, it needs to be acknowledged.

Thank you. Thank you. Thank you.

Hi. I'm reporting my case, hope to be helpful to other one.

In briefly, I've subjected vscode intellisense performance issue, while using SxProps type.

But my performance issues is gone when I give Theme type parameter explicitly to SxProps, SxProps<Theme>.

In mui, they declare SxProps's generic type like this

export type SxProps<Theme extends object = {}> =
  | SystemStyleObject<Theme>
  | ((theme: Theme) => SystemStyleObject<Theme>)
  | Array<boolean | SystemStyleObject<Theme> | ((theme: Theme) => SystemStyleObject<Theme>)>;

package version
"@mui/material": "^5.3.1",
"@mui/styles": "^5.3.0",
"@mui/system": "^5.3.0",

This is detailed article.

https://gist.github.com/casamia918/dafd630a1cdd81935a4587297acaae00

HiChoi-Dev (@casamia918)

I literally just had the same issue as HiChoi-Dev (@casamia918), and the fix actually works. Thank you!

Maybe typescript server needs to improve the complex project support capacity, because we can assume a project is typescript best practices.

Still slow also for me, either JS or TS, plain project without anything installed.
Tried either:

import Button from '@mui/material/Button' or
import { Button } from '@mui/material'

How come that so common framework is just not functional in the most used IDE for JS and TS?

I have tried to exclude node_modules, both in tsconfig.json and settings.json still very slow..

Does someone know how to fix this one?

Taxi4you

Taxi4you nope, I got used with it, hopefully one day will be fixed :)

still very slow, almost unusable.

Enoh Barbu (@enoh-barbu)

Enoh Barbu (@enoh-barbu) One of the most popular frameworks on the probably most used language with the most used IDE, in 2022 and still doesn't work properly :/

Can confirm it is still extremely slow. Using skipLibCheck and increased typescript memory to ~16k does not seem to even remotely improve the situation.
I've tried other libraries and the difference is absolutely staggering, which leaves me with a difficult choice: Do I choose the extremely laggy, but more popular and more documented library, or a less documented counterpart?

I'm heavily leaning towards the latter which should be disappointing to hear.

Taxi4you

Taxi4you nope, I got used with it, hopefully one day will be fixed :)

No way. I WILL choose another library over this issue. Taking over a second to autocomplete a very simple task annoys the crap out of me. I don't understand how anyone can cope with this in a high-pressure environment.

Another random library vs. MUI, this cannot be normal right? (right?)

Was just burned by this, with a single SxProps reference resulting in 10x time and memory usage (70s -> 7s, 4G+ -> 400M).

This eslint rule can be used to

    'no-restricted-syntax': [
      'error',
      {
        selector:
          'TSTypeReference[typeName.name="SxProps"]:not([typeParameters])',
        message:
          'SxProps must have Theme parameter to avoid significant compiler slowdown.',
      },
    ],

my explore and solution: https://github.com/tjx666/ts-perf-issue

my explore and solution: https://github.com/tjx666/ts-perf-issue

Great tips. Thanks.

Navigation Menu

Repository navigation

Type checking/VS Code slow when using MUI #34801

112 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Type checking/VS Code slow when using MUI #34801

Description

Activity

amcasey commented on Oct 30, 2019

jdoklovic commented on Nov 1, 2019

amcasey commented on Nov 1, 2019

zaguiini commented on Nov 8, 2019

dcworldwide commented on Nov 9, 2019

Ravnurin commented on Dec 9, 2019

AlCalzone commented on Dec 9, 2019

amcasey commented on Dec 9, 2019

amcasey commented on Dec 9, 2019

amcasey commented on Dec 10, 2019

AlCalzone commented on Dec 10, 2019

112 remaining items

eps1lon commented on Jan 17, 2022

amcasey commented on Jan 18, 2022

landisdesign commented on Jan 21, 2022

casamia918 commented on Jan 26, 2022

Rodrigo-JM commented on Jan 28, 2022

li1234yun commented on Mar 5, 2022

Taxi4you commented on Apr 1, 2022

enoh-barbu commented on Apr 2, 2022

angelvega93 commented on Apr 2, 2022

Taxi4you commented on Apr 3, 2022

canIchangethispls commented on Jul 24, 2022

canIchangethispls commented on Jul 24, 2022

kpdecker commented on Aug 15, 2023

tjx666 commented on Jun 27, 2024

nbran commented on Jul 29, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions