Revamp dune utop for greater speed

[grayswandyr]

After a public, then private discussion with @rgrinberg , I'm submitting this issue about dune utop. dune utop is very handy for our students but it's slow (> 5s on my 2019 laptop for a project only printing "hello world") when it needs to be rebuilt. The slow part is the linking phase building an ad hoc utop.exe.

While dune utop is perhaps (?) not that useful to an everyday developer, this is the command our students use the most and it seems important, in this respect, to make it fast.

@rgrinberg suggested using TM=$(mktemp) && dune ocaml top > "$TM" && utop -init "$TM" to have a fast experience. If this is indeed equivalent to dune utop in all cases, it might be interesting to redesign dune utop to perform these steps rather than rebuilding utop.exe.

[emillon]

Is it equivalent to using #use_output "dune ocaml top" from within utop? in that case we could also add a shortcut to do that from within utop itself.

[grayswandyr]

It is.
But from a UX point of view, I think it would be good to keep a single short command (such as dune utop) to get a "project-aware" utop environment, rather than launch utop and then, each time you run utop, issue a long utop directive that students will forget or mistype. But as long as we have such a short command, it doesn't really matter if it's a dune or utop feature (in the latter case, the only small issue is that it would be the only command not starting by dune ...).

[gasche]

If @rgrinberg did not suggest to reimplement dune utop in terms of whatever faster method is available, I suppose that there are downsides to the approach of dune ocaml top. Are those explained somewhere that you can point to? I hadn't heard of this before, I occasionally use dune utop and had remarked that it is frustratingly slow, and I wonder if there is documentation somewhere.

[rgrinberg]

There's no upside to using dune utop over dune ocaml top. We just kept dune utop around not to break existing user workflows. Everybody is recommended to use dune ocaml top though.

As for why dune utop is slow, I have no idea but Etienne narrowed it done to the linking command. You can run $ dune utop --trace-file=foo.json and then observe what's slow in foo.json in a viewer like perfetto.

[gasche]

But in this case, why not reimplement dune utop in terms of dune ocaml top? Is this a good idea that you just haven't the time to implement, or are there other reasons? (What are the "user workflows" that would break if the dune utop command was reimplemented internally in this way?)

[rgrinberg]

No strong reason, it just hasn't been done yet.

[emillon]

As for why dune utop is slow, I have no idea but Etienne narrowed it done to the linking command. You can run $ dune utop --trace-file=foo.json and then observe what's slow in foo.json in a viewer like perfetto.

More specifically, in that configuration the ocaml compiler is generating a C file which embeds bytecode in it and at least gcc is pretty slow in compiling this. Not sure if that approach is inherently slow or if we can do something about that.

[rgrinberg]

Why are we linking the toplevel this way? Shouldn't it be enough to just emit the bytecode and run it with the interpreter?

[nojb]

Why are we linking the toplevel this way? Shouldn't it be enough to just emit the bytecode and run it with the interpreter?

I think that will require setting CAML_LD_LIBRARY_PATH, but I don't see why it would be an obstacle, given that Dune is the one launching utop and so it is free to do whatever it wants.

[nojb]

Why are we linking the toplevel this way? Shouldn't it be enough to just emit the bytecode and run it with the interpreter?

I think that will require setting CAML_LD_LIBRARY_PATH, but I don't see why it would be an obstacle, given that Dune is the one launching utop and so it is free to do whatever it wants.

dune/src/dune_rules/utop.ml

Lines 7 to 13 in 0f555db

	let utop_exe =
	(* Use the [.exe] version. As the utop executable is declared with [(modes
	(byte))], the [.exe] correspond the bytecode linked in custom mode. We do
	that so that it works without hassle when generating a utop for a library
	with C stubs. *)
	Filename.concat utop_dir_basename (exe_name ^ Mode.exe_ext Mode.Native)
	;;

[rgrinberg]

Which reminds me, doesn't #use_output "dune ocaml top" not set CAML_LD_LIBRARY_PATH? So I guess it's currently broken with stubs?

[nojb]

Which reminds me, doesn't #use_output "dune ocaml top" not set CAML_LD_LIBRARY_PATH? So I guess it's currently broken with stubs?

It doesn't need to, because the directories set using #directory are used to look up shared libraries for the stubs, so it should work even without setting CAML_LD_LIBRARY_PATH. Setting CAML_LD_LIBRARY_PATH is only necessary if we take the approach of doing a "normal" bytecode link of utop; if we use the init file then it shouldn't be necessary as far as I can see.

[rgrinberg]

Okay in that case there's no point to change the link type and we can just launch utop and set #use_output "dune ocaml top".

[nojb]

Okay in that case there's no point to change the link type and we can just launch utop and set #use_output "dune ocaml top".

I agree.

[nojb]

In #8631 we switched to "normal" (instead of "custom") linking for the utop binary; this should alleviate some of the slowness of dune utop.