Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Guidance on reducing heap usage of large typings?

See original GitHub issue

I maintain google/schema-dts which generates typings for JSON-LD. The generated typings are ~10k loc and involves a lot of type unions (e.g. Thing can be Organization or CreativeWork or Person or …), and these can get pretty nested.

Compiling these works for me and the vast majority of users. But I get constant reports of JavaScript heap OOM errors from users consuming the typings. See google/schema-dts#34. I haven’t been able to repro this at all, but I’m still hoping for some guidance on getting a better memory footprint for the type checker.

FYI, the .d.ts file looks something like this:

Questions (I’d take answers to any of these):

  1. Are there better strategies for writing these in a more memory friendly way? e.g. naming intermediate types, or declaring all properties in one huge object and defining respective types in terms of Pick<>?
  2. Are there any profiling tools that anyone would recommend using to track this down?
  3. any other advice is appreciated.

Unfortunately splitting the types up isn’t an option (at least not obviously) because the types are deeply self referential.

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:2
  • Comments:12 (12 by maintainers)

github_iconTop GitHub Comments

amcaseycommented, May 9, 2020

I ran #37785 on your example and it revealed precisely nothing. So either this is a different class of slowdown than we were expecting or the tool is useless on .d.ts files. I’ll have to investigate more to figure out which.

Eyascommented, Aug 11, 2020

@amcasey if it helps/narrows anything down, some users are reporting that TypeDoc is also OOMing with the linked library. Not sure if TypeDoc uses any of the typescript lib when running through types.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Optimal Heap Limits for Reducing Browser Memory Use - arXiv
In high-performance deployments of garbage-collected systems, setting heap memory limits manually to achieve the optimal trade-off is common [Shang 2020].
Read more >
Identify & Handle Android Builds' Memory Issues - Medium
The GC process can reclaim most of the memory and keeps the heap size between 1.5–3GB size, which makes sense now because it...
Read more >
Performance tuning tips | CLion Documentation - JetBrains
This article gives a summary of helpful techniques that you can use to improve CLion performance on large-scale projects.
Read more >
Tuning For a Small Memory Footprint
The heap must be at least large enough for all objects that are alive at the same time. Preferably the heap should be...
Read more >
Performance.memory - Web APIs - MDN Web Docs
The non-standard and legacy performance.memory property returns the size of the JavaScript heap which can be helpful to measure and reduce ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found