How to improve IDE incremental compilation and suggestion times in a large project?

We have a purescript project with around 320K loc, libraries included. A fresh rebuild on a Macbook Pro M1 with 8 cores and 16GB ram takes around 10 minutes, when other heavy weight processes are closed. This is a slight issue for DX but the real issue is time taken for IDE incremental builds, suggestions and type checking. These can occasionally take up to a minute to load and severely impact DX.

We have already split up the app the into multiple compilation steps. I am looking into using a remote development machines with higher specs. Does anyone have any tips on how to speed up the IDE?

We are using purescript v0.14.5

Thanks!

3 Likes

Our codebase is 100K loc, so a bit smaller, but comparable. Our full build also takes minutes. IDE suggestions are very slow as well. We haven’t seen slow incremental compilation and type checking as such, but my experience suggests that it can be a secondary symptom of the slow suggestions: until suggestion lookup is finished, incremental compilation doesn’t start.

For suggestions, we’ve had great success with limiting the number of suggestions returned. I don’t know what your IDE is, but in VSCode this is controlled by the purescript.autocompleteLimit setting. We set it to 50, figuring that if I get more than 50 suggestions, they’re useless suggestions anyway. This made autocomplete work near-instantly.

5 Likes

Thanks @fsoikin . Yes we’re also using VSCode and I have also set the autocompleteLimit.

What do you mean by IDE incremental compilation? Fast rebuild (when only a particular module is compiled, which is performed by purs ide) on save or full build (which runs purs compile for the whole project, finds changed modules and recompiles them), how long does it take in your case?

2 Likes

Sorry I missed this. We are using fast rebuild on save with the purescript IDE. The exact issue is that many IDE actions take a long time. This includes compilation errors and warnings and suggestions. I assumed this was due to purs ide compilation time but I’m not sure about this.

If I make sure to close all other unneeded programs, the load time is not so long but can often take around 15-20 seconds for automatic imports and 5-10 seconds for type hole suggestions which can be long enough to slow down development.

Here is a screen recording of a slow import:

blob:https://keepvid.com/8a38e0cd-eddf-4bfe-ae33-8a0134b37fcc

I think you will have to copy and paste the link, including “blob” for it to work.

The importing happens from around 0:08s to 0:28s marks

2 Likes

The link you provided doesn’t seem to work for me.

What are the sizes of the problematic modules? Does this happen in smaller/less dependent modules? Did you try to figure out what could cause it in a particularly slow module (by removing its parts/dependencies) just to get a clue what may be the reason in the codebase?

Sorry here is a link that works: https://drive.google.com/file/d/1FNF2kRp0t8CWT3p-bw1HXaF3j87hyL0r/view?usp=sharing

Looking at removing bits of the module now.

Seems like it is quite a big module, do small modules have the same slowness problems?

Also, try to turn off the export and other lenses, just to check.

The module is 1180 lines. Mostly a large Halogen component. On small modules it loads much faster. On an empty module an import takes around 2-3 seconds.