optimize getIndices in IndicesSegmentResponse

[mushao999]

The getIndices method in IndicesSegmentResponse will traverse shards for n+1 times (n is indices count), which can be optimized to just traverse once by using Map and its computeIfAbsent method.
Same logic can be found in IndexSegments’ constructor， where we just traverse shard once.
This PR just want to make elasticsearch code better, thougth getIndices method may be called Infrequently and has no performance issue.

[elasticmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[DaveCTurner]

@elasticmachine ok to test

[DaveCTurner]

Seems like a nice improvement. I left a few suggestions.

[DaveCTurner]

Suggested rename:

Suggested change

	Map<String, List<ShardSegments>> tmpIndicesSegment = new HashMap<>();
	final Map<String, List<ShardSegments>> segmentsByIndex = new HashMap<>();

[DaveCTurner]

Suggest inlining the intermediate variable:

Suggested change

	List<ShardSegments> indexSegments = tmpIndicesSegment.computeIfAbsent(
	shard.getShardRouting().getIndexName(),
	k -> new ArrayList<>()
	);
	indexSegments.add(shard);
	segmentsByIndex.computeIfAbsent(shard.getShardRouting().getIndexName(), n -> new ArrayList<>()).add(shard);

[DaveCTurner]

Oh also please make IndicesSegmentResponse#indicesSegments volatile. I don't see any places where we access it across threads today but it's possible we'd add one in future.

[mushao999]

@DaveCTurner Thank you for your suggestion, I've updated the code.

[DaveCTurner]

Thanks @mushao999, this looks good to me but CI is failing - you need to run ./gradlew spotlessapply to apply the correct formatting. Please don't force-push to PRs once they're being reviewed, it makes it hard to keep track of comments etc.

[mushao999]

Thanks @mushao999, this looks good to me but CI is failing - you need to run ./gradlew spotlessapply to apply the correct formatting. Please don't force-push to PRs once they're being reviewed, it makes it hard to keep track of comments etc.

@DaveCTurner Thank you , I found this problem in jenkins log and have reformat the code. I am sorry for force pushing the code, I did this just to let it keep up with the latest master. No force push later.

[DaveCTurner]

LGTM. It looks like we don't have a huge amount of testing of this API so I added a slightly stronger YAML test in 682e022. I also linked this from #77466 since it aligns closely with that work and I think this would be a problem in clusters with very large numbers of indices.