Optimize computeLocations() and simplify ModelObjectPool location handling

[gnodet]

Summary

Two targeted optimizations in the model building pipeline:

1. computeLocations() — replace Stream with HashMap (model.vm)

Replace Stream.concat().collect(Collectors.toUnmodifiableMap(...)) with HashMap.putAll() + Map.copyOf(), reducing intermediate KeyValueHolder allocations from stream-based map construction.

Also return oldlocs directly when newlocs is empty — the base locations map is already immutable, so the Map.copyOf() was redundant.

2. Add getLocations() accessor and simplify DefaultModelObjectPool (model.vm + DefaultModelObjectPool.java)

The original PoolKey code used getLocationKeys() + getLocation(key) to iterate locations entry by entry because the model had no direct map accessor. This required:

• A separate locationsEqual() method iterating keys one by one
• A separate locationsHashCode() method doing the same for hashing
• A redundant Objects.equals(dep1.getLocationKeys(), dep2.getLocationKeys()) check

Fix: add getLocations() to the generated model, then replace all of the above with:

• Objects.equals(dep1.getLocations(), dep2.getLocations()) for equality
• dep.getLocations().hashCode() for hashing

Changes

File	Insertions	Deletions	Net
src/mdo/model.vm	+17	-4	+13
DefaultModelObjectPool.java	+2	-38	-36
Total	+19	-42	-23

[gnodet]

Clean, well-motivated performance optimization. Both changes — the computeLocations() stream removal and ModelObjectPool simplification via getLocations() — are semantically equivalent to the original behavior. The immutability invariant of the locations map is preserved across all code paths.

Minor: The java.util.stream.Collectors import in model.vm appears to be unused after this change — the only usage was in the computeLocations() stream pipeline (Collectors.toUnmodifiableMap) which is now replaced with HashMap.putAll() + Map.copyOf(). (java.util.stream.Stream is still needed for getLocationKeyStream().)

📋 PR Metadata

Aspect	Current	Suggested
Labels	chore, performance	Consider removing chore — this is a performance optimization, and the performance label is already the better fit

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet