😱 wow!

Did you see any change in performance?

@RyanCavanaugh I think no. I didn't write performance tests, but all regular typescript tests run in same time as usual build.

got an idea how to prevent splitting property declarations and initialisation, using

constructor(public host: TypeCheckerHost, public produceDiagnostics: boolean )

It fixes problem of properties dependency. I`ll try it

@Busyrev as built compiler supports tsc --diagnostics and give you some level of indication of performance, if you build something substantial with the two versions.

I ran our internal performance tests and it looks like there is a large increase in check time. (There were also large increases in emit time, which may just be my hard drive acting up.) There was no change to parse or bind time or memory usage.

Monaco - node (v8.2.1, x64)

Monaco - tsc (x86)

TFS - node (v8.2.1, x64)

TFS - tsc (x86)

I'd really like to see the checker cut down to size -- it's so big that vscode doesn't support collapsing code, and it takes several seconds to update errors. I think some of the candidates for removal from checker.ts were isTypeAssignableTo and typeToString. @sandersn might have some comments.

@andy-ms thanks for tests! I believe we can beat this 25% slowdown.
Now all methods are bound. I'm working on auto binder now, only for methods used not for calling. It can increase speed, may be. And I`m thinking about removing method createTypeChecker from implementation, and implement Typechecker interface directly.

Hi @Busyrev , sorry for the delay. It looks like your branch Busyrev/TypeScript/checker-class-public-experimental is still on the Aug 17 commit "First ugly try to refactor checker.ts". I can run performance tests again if you push to that branch.

That'll be much easier to refactor incrementally if checker.ts would be splitted in modules but it seems there is chicken egg problem here :(

An incremental that could be used is to move some of the variables that createTypeChecker defines near the top into a "context" object and then pass that context object to the functions that use those variables. You could start with those variables that are least used. Once a function no longer makes uses of any variables from the closure it can be extracted.

It might even make sense to have a couple of objects. I could very easily seen all of the type intrinsics defined grouped together on their own object. I see that createTypeChecker is called multiple times in program.ts. Is there any worry about reusing types created by createType across multiple calls to createTypeChecker?

Can someone explain the performance issues? It seems crazy to me that you can't split up a 41k line file because of that. It makes editing it very difficult - not only the performance issues, but you can't even jump to errors or changes using the scrollbar.

@Timmmm I think that there is two major performanse issues:

1. all methods are binded. This may be fixed.
2. using members instead of local variables is slightly slower. And I know no way to speed it up.

This gets asked a ton of times, so here's the short version

Imagine you have this code structure

function fn(x) {
  // There are ~450 of these variables
  let y1 = someFunc1(x);
  let y2 = someFunc2(x);

  // There are ~1200 of these functions
  function a() {
    console.log(y1 - x);
  }
  function b(z) {
    console.log(y2 + x * z);
  }
}

It is a fact in modern JS engines that bare-name lookups like y1 and y2 are much faster than property accesses like obj.y1 and obj.y2. The challenge, then: how do you "split up" fn in a way that preserves that performance improvement?