opam exec overhead

[jonahbeckford]

Something like the following is instantaneous:

opam.exe: [EXEC:312] ["C:\Users\WDAGUT~1\AppData\Local\Programs\DKMLNA~1\tools\MSYS2\usr\bin\env.exe"
                      "C:\Users\WDAGUT~1\AppData\Local\Programs\DKMLNA~1\bin\opam-real.exe"
                      "--version"]
2.2.0~alpha0~20221228

But the following (opam exec -- C:\Windows\System32\where.exe /?) visibly pauses for at least one second before executing the command:

opam.exe: [EXEC:296] ["C:\Users\WDAGUT~1\AppData\Local\Programs\DKMLNA~1\tools\MSYS2\usr\bin\env.exe"
                      "C:\Users\WDAGUT~1\AppData\Local\Programs\DKMLNA~1\bin\opam-real.exe"
                      "exec" "--" "C:\Windows\System32\where.exe" "/?"]

I get this one second pause with opam var as well.

This is related to https://github.com/ocaml/opam/issues/5741

[kit-ty-kate]

This is related to #5741

That indeed looks related to this as opam exec -- reads a couple files (to lead the switch state). Do you have any idea what could be different from Unix-likes when reading files?

[jonahbeckford]

Speed test for my mac M1 (the green numbers on right hand side are statistically accurate; ignore the speedometers which are just a snapshot of fluctuations):

[jonahbeckford]

And for my Windows drive Y: which is where I have my current opam root and opam switch.

[jonahbeckford]

So, in the numbers I am reporting the mac M1 mini drive is significantly faster. (I have a Z: drive that is faster than the mac M1, but I don't use that for opam. And I expect my slower Y: drive is more typical for average Windows users so I'll focus on my Y: drive.)

[jonahbeckford]

I realized that this issue (not #5741 though) I had measured using Windows Sandbox. The opam root would have been a virtualized file system; that is not representative. So, in the table below you'll see numbers from my Y: drive ... the same drive I attached disk speed numbers.

Times rounded to the nearest tenth of a second. The opam-real is regular opam executable without any DkML shims.

Time	What	Where
0.2s	measure-command { opam-real --version }	Windows
0.1s	time opam --version	M1
0.3s	measure-command { opam-real var --global }	Windows
0.1s	time opam var --global	M1
0.0s	measure-command { C:\Windows\System32\where.exe /? }	Windows
0.0s	time /usr/bin/true	M1
0.2s	measure-command { opam-real exec -- C:\Windows\System32\where.exe /? }	Windows
0.1s	time opam exec -- /usr/bin/true	M1

[jonahbeckford]

Conclusion:

• A second overhead is not representative for SSD drives (I updated the issue title).
• But 1-2 tenths of a second is still a lot of overhead of opam exec for commonplace SSD drives. It becomes very noticeable for slower I/O.
• The operating system (Windows, macOS) is irrelevant. The drive speed is the relevant factor. (I updated the issue title).

I think this is lower priority but given that students especially are often on older Windows hardware (and definitely not SSDs), this hit will be noticeable for a significant fraction of new users.