So I cherry picked these commit to the 4.14 branch to have meaningful benchmarks.

As usual I used the Irmin codebase as example.

This seems to indicate that there is no perceptible build time increase by performing the indexing.
However the cmt size increase (as it was to be expected) is noticiable.

Should I introduce a flag to enable indexation ? And maybe another flag that don't store the typedtree in the cmt files ?

@lpw25 I was able to fix the sharing issue (there was a very silly mistake in my previous attempt). I updated the results in the previous comment.

On the whole Irmin codebase (65K lines in ml files), the indexed data adds 30M (from 330M to 360M), that is a 10% increase.

But the index is incomplete right now, the only nodes I consider right now are:

• Texp_ident
• Ttyp_constr
• Tmod_ident

Do you have in mind what other nodes would be important to consider for this first version ?
The main drawback of having the compiler do the indexing is that we are less flexibility in what we can add/remove.

I guess the potential candidates are every occurrence of Longident.t in the parsetree. I suppose it depends on which sorts of items we intend to support "find all uses". For instance, if you want to support it for record fields then you'll need to include all the places with Longident.ts that correspond to those.

I guess the potential candidates are every occurrence of Longident.t in the parsetree. I suppose it depends on which sorts of items we intend to support "find all uses". For instance, if you want to support it for record fields then you'll need to include all the places with Longident.ts that correspond to those.

Right, I am not sure were we should put the cursor for the first iteration, I will make a list and start filling cases.
I will also add some tests.

What do you think about making the indexation opt-in with a flag ?
10% growth of all installed cmts is still a lot of wasted space if we don't care about indexing the whole switch.

I think it's worth avoiding a flag if possible. Before add one I think it would be worth investigating the sources of the size increase -- in case there are simple things that can be done to improve things. It would also be worth benchmarking it on a different project -- my understanding is that Irmin has particularly large shapes for some reason.

I would expect the size increase to be directly related to the shapes we store. This does mean that Irmin should be more impacted than other projects.

Since I have switches with all Irmin dependencies I can simply check the sizes of the cmts in these switches:

It looks quite good ! The switch contains 207 packages, including Irmin itself.

Superseded by #12508