perf: optimize term::relation_with()

[Eh2406]

In #27 it was measured that we spend a lot of our runtime in intersections in relation_with. For that use case we do not need the exact list of what versions are in the intersection just a trinary state. So this adds a function to Range to compute that directly.

Criterion thinks this is a ~20% improvement in runtime of the benchmarks from #34.
This is mostly because of skipping the cache miss and allocation of making a new Range. But also because we can short circuit when we see a Relation::Inconclusive.

This still needs wordsmithing.

[mpizenberg]

At a first glance, it seems to be a non-negligible readability/performance tradeoff. Would you mind waiting a bit for those kind of perf improvements? It also would complicate the promising Range trait approach I believe

[Eh2406]

It also would complicate the promising Range trait approach I believe

Yes (cc #49) it would need to be added to the proposed trate. We could provide a default implementation that uses intersection as we do now, and users can override it when performance matters.

Would you mind waiting a bit for those kind of perf improvements?

Yes, we can definitely weight. Lets get 0.2 out.

[Eh2406]

Using the elm benchmark this was a smaller improvement then the noize. I.E. Criterion thought this was faster but not statistically significantly so. So this should be put on the back burner for a while. When we find other ways to make the elm benchmark faster, this may pull its weight.

[Eh2406]

running on top of #74 using the benchmarks from #75

Benchmarking large_cases/elm-packages_str_SemanticVersion.ron: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 20.0s. You may wish to increase target time to 31.2s, or reduce sample count to 60.
large_cases/elm-packages_str_SemanticVersion.ron                                                                            
                        time:   [310.00 ms 310.27 ms 310.55 ms]
                        change: [-6.6554% -6.5353% -6.4141%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild
large_cases/large_case_u16_NumberVersion.ron                                                                             
                        time:   [16.331 ms 16.344 ms 16.357 ms]
                        change: [-9.1269% -9.0116% -8.8980%] (p = 0.00 < 0.05)
                        Performance has improved.

So it now looks like an improvement. Can the code be cleaned up to make it worth it? It needs work, but we have something to talk about.

[mpizenberg]

I'm personally still not very attracted by this change. Thanks to all other changes, the perf improvement here is down to 9% where it was roughly 20% at the beginning. And this makes the code more complex to read and to explain, it also doesn't match anymore with the expression in the guide documentation. Let's keep it around and focus on features important for cargo instead. Once we have something working for cargo, we can see if that perf improvement is still worth the change.

[Eh2406]

I am closing, thanks to SmallVec this is not the best perf/complexity change we can make.

[Eh2406]

In #157 (comment) reported large improvements from reducing the calls to V.clone(), so at some point this optimization will be helpful to them.