Add diversityScoreFunctionFor to avoid creation of wrapper object

[michaeljmarshall]

In a profile of CC, I found that we create DefaultSearchScoreProvider many times only to access its wrapped object. Here is a screen shot of the memory profile:

We only ever create the DefaultSearchScoreProvider to access the ScoreFunction it wraps. This PR adds a method to get directly to the ScoreFunction.

However, in running the benchmark, I found that there was no significant difference, so perhaps there is no real benefit. I am not sure whether we want to merge this based on the theory alone that we can avoid the allocation or if this is too insignificant to merge, considering @marianotepper plans to overhaul the whole design with #585

% BENCHMARK_NAME="PQDistanceCalculationBenchmark"                                  
mvn clean install -DskipTests=true
java --enable-native-access=ALL-UNNAMED \
  --add-modules=jdk.incubator.vector \
  -XX:+HeapDumpOnOutOfMemoryError \
  -Xmx20G -Djvector.experimental.enable_native_vectorization=true \
  -jar benchmarks-jmh/target/benchmarks-jmh-4.0.0-rc.7-SNAPSHOT.jar $BENCHMARK_NAME

Benchmark                                                         (M)  (dimension)  (queryCount)  (vectorCount)  Mode  Cnt    Score     Error  Units
PQDistanceCalculationBenchmark.diversityCalculation                 0         1536           100          10000  avgt    3  259.194 ±   7.059  ms/op
PQDistanceCalculationBenchmark.diversityCalculation                16         1536           100          10000  avgt    3   23.637 ±   0.794  ms/op
PQDistanceCalculationBenchmark.diversityCalculation                64         1536           100          10000  avgt    3   70.952 ±  33.364  ms/op
PQDistanceCalculationBenchmark.diversityCalculation               192         1536           100          10000  avgt    3  215.635 ±  59.209  ms/op
PQDistanceCalculationBenchmark.diversityCalculationScoreProvider    0         1536           100          10000  avgt    3  275.298 ±  43.395  ms/op
PQDistanceCalculationBenchmark.diversityCalculationScoreProvider   16         1536           100          10000  avgt    3   24.119 ±   1.243  ms/op
PQDistanceCalculationBenchmark.diversityCalculationScoreProvider   64         1536           100          10000  avgt    3   70.436 ±  14.631  ms/op
PQDistanceCalculationBenchmark.diversityCalculationScoreProvider  192         1536           100          10000  avgt    3  220.359 ± 171.887  ms/op

[github-actions]

Before you submit for review:

• Does your PR follow guidelines from CONTRIBUTIONS.md?
• Did you summarize what this PR does clearly and concisely?
• Did you include performance data for changes which may be performance impacting?
• Did you include useful docs for any user-facing changes or features?
• Did you include useful javadocs for developer oriented changes, explaining new concepts or key changes?
• Did you trigger and review regression testing results against the base branch via Run Bench Main?
• Did you adhere to the code formatting guidelines (TBD)
• Did you group your changes for easy review, providing meaningful descriptions for each commit?
• Did you ensure that all files contain the correct copyright header?

If you did not complete any of these, then please explain below.

[eolivelli]

what's the score in the benchmark table above ?
this change should reduce the number of allocations and the pressure on GC, it is possible that in a microbenchmark that does not run the entire system the benefits of this change are not visible.

In the profile these allocations are 38% of all the allocations in the JVM, and this is very big

[marianotepper]

LGTM

[michaeljmarshall]

what's the score in the benchmark table above ? this change should reduce the number of allocations and the pressure on GC, it is possible that in a microbenchmark that does not run the entire system the benefits of this change are not visible.

In the profile these allocations are 38% of all the allocations in the JVM, and this is very big

The profile indicates that the results without this change are in the same neighborhood (due to error bounds) of performance. There is no reason to leave it in place though, and I agree with you that the profile may not have enough GC pressure to expose the hotspot.

[MarkWolters]

LGTM

[tlwillke]

LGTM.