Analyze and reduce IFD usage

[raphiz]

Using IFDs is a conscious choice in this library, and it's not inherently a bad thing as long as we use them sparingly.
However, I'd like to keep IFDs to a minimum and optimize for that.

But before we tune anything, I want to quantify the real cost: measure the current implementation and compare it to an optimized version.

This was discussed in #33 .

[fkz]

One drawback of using many imports from derivations is that the building of these derivations can't be parallelized, even if there is no real dependencies between them, because nix evaluation is not parallelized (except, possibly, when using experimental support of determinate nix with parallel evaluations, as described in https://docs.determinate.systems/determinate-nix/#parallel-evaluation, but that is not available in normal nix).

So I think the parsing of the xml file is a good use of IFD.

The fetchArtificat of the module files is more problematic, I think, because:

• It's linear in the number of module files, so possibly hundreds of IFDs
• When the files are not yet available, it is probably bound by network latency (as it's rather small); so it is parallelizable pretty well

If we would switch that to not use IFDs, one drawback is that the "Found multiple matching urls with name" error, which currently happens already in evaluation phase, would then only be detected during instantiation, so possibly a bit later.

[raphiz]

totally agree.

However, fetching the module files inside the fetchArtifact derivations works but then we don't have the url suffix information available later when reconstructing the same m2 repository structure. It's important to use the same url here, otherwise gradle can't find the file with the url suffix.

I was thinking that instead of putting the file directly in the store, it could be a directory with the a single file with it's original name - but that won't work because we then have to change the outputHashMode which will produce a different hash.