basic tracing

[c-cube]

This is WIP.

I'm adding tracing to find why opam is so slow on my machine. It gives excellent insights on where time is spent (e.g after opam upd, all 30k files are read one by one, to update the cache).

I've been instrumenting things as I explore but it needs to be more principled in general I think.

The overhead when tracing is not active (ie TRACE_FILE is not set) should be fairly low.

[kit-ty-kate]

Thanks a lot for this! I have a couple of questions:

• I’m not familiar with this tracing format. Is it used by a visualisation tool? If so which one?
• If not, what are the advantages compared to --debug-level=3?
• Is the dependency on mtime necessary or could we use something that already exists for --debug-level=3 for example?

[c-cube]

• the tracing format is the classic JSON file for chrome://tracing, which can also be read by https://ui.perfetto.dev/
  (see also past example of this 1). So you can easily visualize it.

  It can look like this:
  

• I think we could use Unix.gettimeofday() instead, I think, we don't need that high precision in general. I got a bit over enthusiastic.

[kit-ty-kate]

LGTM on first glance

[kit-ty-kate]

We’re trying to get 2.2.0 out the door asap and i’d prefer to merge this after the release to avoid unnecessary time spent in extra maintenance and CI work (don’t worry the CI failure is unrelated to you changes).
Is that ok for you?

[c-cube]

Of course, no worries! This is really a tool to debug/improve opam itself, not something end users urgently need, I think.