People with large codebases, what are the compile times like?

1

I need to know. I’m going nuts with typescript on a large project, the type system is practically useless because of how long it takes for the type checker to run.

1 Like
2

We have around 3000 rescript files in the project (including dependencies). It takes 7510 ms for the first build, and then 50-400ms on file change in the watch mode.

1 Like
3

I have a fairly large project here, a monorepo consisting of eight packages. A clean complete build takes about 10 seconds, that is about 90k lines of ReScript code. Incremental builds are instant (same as @DZakh’s) even if I extend some type in a top level package that the others depend on.

In general, the rather simple Hindley-Milner typechecking algorithm of ReScript should be much faster than the extremely complex and turing-complete type checker of TypeScript.

2 Likes
4

@DZakh @fham Do your projects use interface files extensively? I know that they’re supposed to impove compile times but I wonder how much do they do in practice.

5

No, we don’t really have them

1 Like
6

I would not say extensively, but around 20 % of all .res files are accompanied by a .resi file. I use them mostly for modules that contain a lot of internal helper functions and React components that must only export their one default component but nothing else (or it will break fast-refresh).

I guess we would even have less of them, if it was not so easy to break fast-refresh (you always need to think about adding %%private to every function and for submodules it does not work).

1 Like
7

A monorepo of ~40k lines of ReScript (excluding external dependencies) takes about 9 seconds for a clean build. Incremental builds are “almost instant”. We don’t use .resi files.

1 Like
8

With 35000 lines of code in 209 .res files (including .resi would add 3700 lines in 34 files), it takes about 10s to build on my 10 or so year old home computer. My work computer would probably cut that in half, if not more.

Incremental builds are usually effectively instant.

1 Like
9

I’ve never worked on a large typescript project (phew!) so I’d be interested in hearing what the equivalent compile time would be there.

1 Like
11

7 million LOC. Type checking the project takes minutes. The type checker is barely functional in the IDE.

12

we are at 45kloc rescript, clean build with dependencies takes 70s on this 2.6G i7 macbook pro, but i have seen it be noticeably slower on other devs machines. updates are much faster to the poitn that its not a problem

13

@mouton That case in particular sounds incredibly slow. What and how are you compiling the code?

14

ah not sure how you mean. yarn rescript build -with-deps

15

I mean how many dependencies do you have? Any syntax extensions in this setup?

16 
  "bs-dependencies": [
    "rescript-webapi",
    "@rescript/react",
    "rescript-apollo-client",
    "@reasonml-community/graphql-ppx",
    "@nobleai/rescript-cypress",
    "@nobleai/rescript-rxjs"
  ],

  "bsc-flags": ["-w -3-48"],

Fairly heavy use of functors, and a 22k line Highcharts binding file maybe?

17

How are you running type checks in your project? Running tsc --noEmit each time is slow, using --watch or using an IDE that can talk to TypeScript’s Language Service will be much faster.

18

For such a large project, you may see benefits from splitting it into multiple packages and configure TypeScript to use project references.

2 Likes
19

LOC is half the problem. The type checker often fails because there are these massive complex nested types that are built on subsets or supersets of other existing types, which themselves could be nested complex types. The types are often derived from other types and use generics, etc etc. I used to think a turing complete type system was cool, I much prefer actually having a usable type system…

5 Likes
20

Here is what we have:
Files: 1,475 LOC: 88,852
Time: ~81s

1 Like