OCaml and Windows: is it normal for development to be (much) slower?

Ecosystem
1

I’m trying to do some tests with OCaml on Windows, using a virtual machine, but the tooling performance is abysmal: a single opam update takes 6 minutes; dune build sometimes spends more than a minute seemingly doing nothing, and only then starts updating the count of remaining tasks; compilation is very slow, even if the VM has access to 8 cores, the host is idle, etc.

Apparently this might be related to disk accesses, but I’m not sure.

I have a relatively new computer (recent Thinkpad with AMD Ryzen 7 PRO, NVMe SSD, etc), and on the Linux host things are very snappy, but the Windows VM is really slow.

I’ll try to get a real Windows on another computer to speed things up, but even when I did it in the past, it still felt sluggish compared to Linux.

So, my question is: is this “normal”?

Is it unavoidable, maybe due to the “unixy-like” nature of OCaml on Windows (with Cygwin by default), which imposes lots of small file accesses, for which apparently Windows is not optimized?

Or is it mostly due to the VM, and for you people developing OCaml on a “real” Windows, there’s no performance penalty?

Might it be related to the compiler? If I switch to MSVC, will it greatly improve things?

By the way, I’m currently using Windows 11, but it also used to happen with Windows 10.

Note: I’m not considering WSL here, since my goal is to ensure that Windows users need to do as little as possible, and many cannot/do not want to use WSL.

2

Are you positive that this is due only to the compiler tooling ? Have a look at the task manager (right click the windows menu in the task bar, if you don’t have a right mouse button focus the element and type shift-F10).

A couple of months ago I installed a Win11 in a VM, things were already incredibly slow because I was running an x86 guest on an ARM host but then there was an huge amount of churn being performed by Windows itself that was rendering the whole system unusable interactively.

3

Lost of small files, lots of process executions: indeed, both file and process operations are less optimized on Windows than on Un*x, so you pay a penalty when porting programs that use a typical Un*x approach to Windows. Windows also runs a bunch of background processes (antivirus, etc) that can further slow down file and process operations.

I assume you are currently using the Mingw64 compiler? In any case, the answer is “no” for the most part.

This is not the case. Even when using Windows natively, there is a performance penalty vs Un*x. Of course, using a native instance will make everything a bit faster, but you shouldn’t expect parity with an equivalent Un*x setup.

Cheers,
Nicolas

1 Like
4

Sometimes there are indeed some processes such as antimalware, or Windows updates, but most of the time I see absolutely nothing in the task manager. And the slowness is mostly constant. I just retried typing date; opam update; date on PowerShell (I don’t know the equivalent of time on it), and it took more than 3 minutes.

Anyway, I’ll see with the non-VM Windows, but if you have performance tips specific to Windows, I’ll gladly take them.

5

Have you tried working in a dev drive or WSL? while im not using ocaml on a windows machine myself, i had significant improvements when running npm install within wsl, or when placing my project on a dev drive while disabling the scanning for dev drives in windows defender.

3 Likes
6

I didn’t know “dev drives” existed, thanks for the hint. I’ll try it soon.

In fact, I have a question: is there a way to install OCaml on a dev drive?

I mean, it seems that it will create a D:, but since opam installs itself by default in C:\Users\user\AppData\, even if I create a dev drive D:, opam will not be there, so it won’t help much, will it?

I never worked with a dev drive so maybe it’s possible, but the documentation seems to indicate it would be a separate drive…

7

Darn, I should have tried this before… simply adding C:\Users\<user>\AppData\Local\opam to the exclusions directory for the Windows antivirus (Windows antiwork, I should say, seeing how much work it prevented me from doing) seems to have reduced the time for opam update from 4-5 minutes to 1 minute. (And when I looked at the task manager, it never showed antimalware as using CPU or something else, so it didn’t look like the culprit.)

Are there other folders that I should exclude? Caches or some other data used by opam/OCaml in a specific directory?

3 Likes
8

Funny thin lg is macOS has a very similar issue macOS - cargo-nextest

1 Like
9

On my Windows 11 Msys2 prompt:

$ time opam update
…
real.  1m22s
10

Indeed closer to “home” it’s mentioned in this issue. Nowadays I have both my editor and terminal in that list and I no longer see the hangs.

2 Likes
11

In the same vein, it’s important to disable (and perhaps uninstall? I forget) OneDrive when using Windows under a VM. That can also cause it to crawl. Note MS loves to activate OneDrive without you asking…

1 Like
12

On the opam side, it is known. We are currently doing a big refactoring to be able to no longer read/write tons of small files (repo opam files) in order to speedup `opam update` on windows (among others). It should be available on the next release.

7 Likes