Docs on improving compilation speed

[ghost]

With the --watch flag on, a recompile of an existing file generally takes 4 seconds now in our project. This isn't terrible at all, but the wait time has grown since we started using it.

I was wondering what factors affect incremental compilation speed? With TypeScript gaining widespread adoption, I think it'll be very important to developer experience to have a doc page detailing the main contributors to incremental compilation time and ways to improve it.

P.S. Note I meant incremental compilation speed with --watch, not a full recompile.

[ghost]

Just did some simple benchmarks with tsc --watch, here are the results:

• Editing & saving a single TS file (tsconfig.json only watches this file):
  • 11KB = really fast
  • 3MB = ~3 seconds
  • 6MB = ~6 seconds

Note: I padded out the file by basically copying & pasting a bunch of console.log statements.

I'm also working on a project which has about 3MB of TypeScript code spread across many files. The incremental transpilation time is about 3-4 seconds as well, so it seems that 1MB of TypeScript code = 1 second of incremental transpilation time on my machine. This seem to indicate that there is a fairly linear relationship between the size of the code being watched and compile time (regardless of number of files that code is spread across).

Now I checked how this might be affected by imports:

• Saving a small TS file importing a 4MB file = slow (~4 seconds)
• Saving a small TS file importing a small file which imports a 4MB file = still slow
• Saving a small TS file importing an external package with large typings file (well just index.ts, not a true declarations file) = still slow
• Saving a small TS file importing an external package with small typings file for a large codebase = very fast

So there you have it, one definite way to make compilation faster is to factor out the code to separate packages with declaration files.

[StokeMasterJack]

It would be nice to know what types of things can cause a project to compile slowly. For example, if certain language features (large unions?? or generics?? or something else) will result in compilation slow-down, then developers can make decide if trade off is worth it.

Also, if some 3rd party libs are known to cause major slow downs, that would be good to know also.

At present, my #1 problem with TypeScript is the slow compile times. And the fact that the IDE is so slow to respond.

[WEREMSOFT]

I just made a simple script that creates a typescript project, so I can parametrize certain characteristics. Then run tsc.

The only factor I found so far is file count and line count. Generics didn't do anything. Unions don't do anything.

Any idea that what else can I test?

[StokeMasterJack]

Interesting. The file count thing. I tend to prefer lots of small files. Might that be killing my perf?

…

On Sat, Jul 27, 2019 at 2:45 PM WEREMSOFT ***@***.***> wrote: I just made a simple script that creates a typescript project, so I can parametrize certain characteristics. Then run tsc. The only factor I found so far is file count and line count. Generics didn't do anything. Unions don't do anything. Any idea that what else can I test? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10878?email_source=notifications&email_token=AAA6DVIKHE3IY5JQLECIGHTQBS6W3A5CNFSM4CPMJMU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD26TEEI#issuecomment-515715601>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA6DVM2ONWPOIZW3657IILQBS6W3ANCNFSM4CPMJMUQ> .

-- Dave Ford Developer and Trainer Smart Soft https://smart-soft.com <http://www.smart-soft.com> https://twitter.com/@daveford https://medium.com/@daveford

[Pauan]

@WEREMSOFT I recommend adding in tests for this["foo"], in particular like this:

class Foo {
    private _foo: number = 1;
}

class Bar extends Foo {
    private _bar: number = 2;
}


class Qux {
    public _qux!: Foo;

    public get qux(): this["_qux"] {
        return this._qux;
    }
}

class Corge extends Qux {
    public _qux!: Bar;
}


const x1: Foo = new Qux().qux;
const x2: Bar = new Corge().qux;

We use this pattern a lot. The things to parameterize are how deeply nested the class hierarchy is, how many methods use the this["foo"] type, and how big the classes are (e.g. number of methods/properties).

[pimterry]

One interesting example is this change to the styled-components types, which increased compile time by 20x. Background discussion here: #30663.

It would be interesting to explore why; I'd love some principles to avoid issues like that in my own code, and tools to find problematic types in general in large codebases. Issues aren't always going to be caused by an obvious dependency upgrade like this.

#31612 might also be interesting, as another catastrophic performance case that docs/tooling should warn you about, and show you how to avoid.