Redundant computation for exact nearest neighbors

[huynmg]

When running the knnPerfTest multiple times with different quantization levels, I noticed that the true nearest neighbors are recomputed and cached to different files each time, which is not necessary. This is because the indexPath is used to calculate the hash key for caching the true nearest neighbors.

I think this is redundant because the true nearest neighbors should be index-agnostic. Should we remove indexPath as a hash parameter ?

luceneutil/src/main/knn/KnnGraphTester.java

Lines 1025 to 1029 in 3184d64

	private int[][] getExactNN(Path docPath, Path indexPath, Path queryPath, int queryStartIndex) throws IOException, InterruptedException {
	// look in working directory for cached nn file
	String hash = Integer.toString(Objects.hash(docPath, indexPath, queryPath, numDocs, numQueryVectors, topK, similarityFunction.ordinal(), parentJoin, queryStartIndex, prefilter ? selectivity : 1f, prefilter ? randomSeed : 0f), 36);
	String nnFileName = "nn-" + hash + ".bin";
	Path nnPath = Paths.get(nnFileName);

[mikemccand]

Whoa, good catch! I wonder why we added indexPath? If there's some other interesting variable going into indexPath that does affect the exact NN cache, we should consume that variable's value directly into the hashing for the exact NN cache filename.

[huynmg]

indexPath was added here when we added support for pre-filtering: #337

But we already added selectivity and randomSeed to the hash input, so I'm not sure why indexPath is still needed.

[huynmg]

I created a pull request here: #403