Repository navigation
Repeated conditional spreading of object literals results in OOM #40754
Description
TypeScript Version: nightly (fc03982)
Search Terms: spread, union, oom
Playground Link: link
Related Issues: #34853 addressed a related issue
An internal partner team is using this to conditionally override CSS properties (e.g. ...sizeLimited && { width: 100, height: 100 } and is seeing OOM crashes in tsc and poor editor responsiveness.
Activity
amcasey commentedon Sep 24, 2020
The two most obvious solutions are:
getSpreadType).Edit: current plan is to do both.
weswigham commentedon Sep 24, 2020
#34853 Originally handled objects with more than one key - it was just pared down to lower potential impact. If we have a good usecase, the fix can be broadened to objects with multiple keys.
amcasey commentedon Sep 24, 2020
I think retaining the union is valuable if it's small - a few dozen shapes - but not if it's large. In the examples I'm looking at, they don't want the union at any size - the result is immediately cast to an uber type with all properties as optional.
Enforce a size limit in getSpreadType
MrAndersen1 commentedon Sep 25, 2020
Just wanted to say that there are those of us who very much are interested in the individual shapes of 50+ literal objects in a union. I realise the performance impact though and perhaps our setup is sub-optimal, so maybe the solution for us would be to sacrifice some usability and create smaller unions that would have some overlap but would clear the bar.
However I'm not trying to start an argument here :) I just wanted to make it known.
amcasey commentedon Sep 25, 2020
MrAndersen1 can you tell me more about your use case? How many shapes do you usually need? Hundreds? Thousands?
amcasey commentedon Sep 25, 2020
Follow-up question: if you're already doing this, are you having performance problems?
MrAndersen1 commentedon Sep 25, 2020
Andrew Casey (@amcasey) Oh no I don't expect us to ever breach 100. Usually old content gets removed which reduces the unions some.
Yeah we do have performance issues, however I have not sat down to find the root cause. Whenever you edit structures of these unions, however, vsCode is rather sluggish. Compilation time is high too but I'm not confident to point fingers at anything.
So the use-case goes something like: we have a lot of standalone projects, ~50-60, they do share a lot of code though. This shared codebase contains code to write, let's call it a tutorial, for all projects. Now most projects use the same shapes/instructions that composes a tutorial but whenever a new project needs a new shape they all get access to it. These tutorials are written in the shared codebase in order to be easy to expose.
We could obviously make these tutorials/tutorial-instructions project-specific but that won't happen unless it becomes a big issue.
Hope I made any sense.
Oh and while I don't invoke tsc manually we do increase node's --max-old-space-size=8192 for the script that does, otherwise it crashes.
amcasey commentedon Sep 25, 2020
MrAndersen1 50 is a made-up number, so I certainly have no objection to using 100 instead. 😄
I don't suppose you can share a link to your repo?
MrAndersen1 commentedon Sep 25, 2020
Andrew Casey (@amcasey) well, see, thats all up to you guys :) we did get issues on an earlier version of typescript, 3.7.3 I think it was, which I believe was due to some limit being hit. That could be resolved by updating to 4.0.2 however, which I was grateful for heh.
No I can't share it sorry, would if I could.
amcasey commentedon Sep 25, 2020
Sounds like we want to do something similar to reverting 7181c2a, probably in the 4.2 timeframe.
amcasey commentedon Sep 30, 2020
Re-opening, since we decided to fix the perf issue too.
amcasey commentedon Sep 30, 2020
The remaining work is targeting post-4.1.