Skip to content

Enhancement: Investigate caching type checking APIs #6425

Closed
@JoshuaKGoldberg

Description

@JoshuaKGoldberg

Before You File a Proposal Please Confirm You Have Done The Following...

Relevant Package

typescript-estree

My proposal is suitable for this project

  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Continuing from #6404 (comment): we've been talking off-and-on for ages now about adding a thin layer of caching around TypeScript's type checking APIs.

do we want to do a weakmap memo on these? Eg

function memoize<TNode, TRet>(fn: (node: TNode) => TRet): (node: TNode) => TRet {
  const cache = new WeakMap<TNode, TRet>();

  return (node) => {
    const cachedRet = cache.get(node);
    if (cachedRet) {
      return cachedRet;
    }

    const newRet = fn(node);
    cachedRet = cache.set(node, newRet);
    return newRet;
  };
}

That would allow us to enforce that if two rules request the exact same node then we'll 100% use a fast path.

Doing a quick look at the implementation of getTypeAtLocation - it doesn't do any fast caching, so it does do a bunch of work.

IDK if this sort of thing would actually save any real time though - would be worth a test. Maybe we can file an issue to look at this later?

Additional Info

This'll require performance testing. Does it actually speed things up? Does it cause out-of-memory issues on our repo? Let's find out!

Strong candidate for including in the v6 betas. I'd like to get real world user testing to make sure this doesn't explode anybody.

Metadata

Metadata

Labels

accepting prsGo ahead, send a pull request that resolves this issueenhancementNew feature or requestpackage: typescript-estreeIssues related to @typescript-eslint/typescript-estreeperformanceIssues regarding performance

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions