Replace PathCopyingPersistentTreeMap hash and size calculation

[Druidos]

Replace PathCopyingPersistentTreeMap hash and size calculation from lazy linear algorithm to pre-calculations, which is efficient for public copying methods

[PhilippWendler]

Thanks!

While this certainly increases the performance for some users, it causes higher memory usage for all users of this data structure due to the new fields in the node class. So I would like to understand the effects a little bit better before merging this.

Do you have any numbers on how much improves this performance or how much it increases memory usage in practice?
What is your use case that benefits from this? In CPAchecker, for example, we apply hash-code caching for these maps outside of them in those cases where we feel it is relevant, is this possible for you as well?

[Druidos]

If memory consumption is critical, then I will move hash and size calculation from Node into PathCopyingPersistentTreeMap on put/remove-AndCopy.
Main idea is to optimize equals(). The hashcode calculation is obtained as a side result of the size calculation.
For example, following code twice iterates by whole pMap to identify size change:

boolean compare(PathCopyingPersistentTreeMap<Integer, Integer> pMap) {
    PathCopyingPersistentTreeMap<Integer, Integer> comp = pMap.putAndCopy(1,1);
    return comp.equals(pMap);
}

Exact numbers about performance I can provide later.

[PhilippWendler]

I now realized one thing: Caching the hashCode() strictly speaking violates the Java API for map's hashCode(), because the hash code of a map depends on the hash code of all keys and values, and in particular the values need not be immutable and may change. Then the hash code of a map needs to reflect this.

Now, it is unlikely that someone would use a map with mutable values, actually change them, and then also depend on the map's hash code. More likely are cases where either the map's hash code is not used at all, or where the hash code is used but everything is immutable. But it could happen, and it would certainly lead to very confusing errors and costly debugging. So it would be better to not do this.

Tracking the size differences in the way that is discussed here would be possible, though. If someone wants to pick this up they can do so.

[PhilippWendler]

However, we need development to be done inside this repository such that we get CI results. So I am closing this PR, if work is taken up again, a new PR from an internal branch needs to be created.