Improve memory usage and performance of LabelingMapping.

[maarzt]

This PR contains many ideas to improve the performance of LabelingMapping.

Changes by @tpietzsch

• All sets in Labeling.setsByIndex are backed by one consecutive list of there elements stored in Labeling.data. This saves a lot of array headers. (This solution couldn't show it's full performance, as Labeling.internedSet is a Map<Set, InternedSet> where regular HashSets where used as keys. A lot more memory can be saved when InternedSet is used a the key as well.)

Changes by @maarzt

• Have a bimapping between labels and integer ids. Instead of using Set use a set of integers. The set of integers is represented as a sorted TIntArrayList. Advantages:
  • Two lists of ints can be much faster compared than two Set.
• Have a dedicated class 'SortedInts' to represent the set of integers, which internally uses a sorted integer array:
  • SortedInts has a much better hash code, improving the performance of the internedSet Hashmap.
• Use a better hash function in AddRemoveCacheMap.
• Use ReferenceQueue with WeakReference:
  • This improves performance of the clearWeakReferences method. And as a side effect fixes problems with concurrent modification issues of LabelingMapping.cacheMaps.
• Fix hashCode and equals method of InternedSet

[maarzt]

@tpietzsch There is much room for improvement still:

1. The importened job that InternedSet currently does is mapping a list of ints to Set. This functionallity could by moved into LabelingType, we wouldn't need the InternedSet objects anymore. The Map<SortedInts, InternedSet> internedSets could be changed to TObjectIntMap setToIndex than.
2. SortedInts could be replaced in a mastodon-collection way. The difficult part would be to implement something functionally equivalent to HashMap<SortedInts, Integer>.

Both changes combined would remove all jave object header overhead in LabelMapping.

[tpietzsch]

@maarzt Nice!

As I suspected, making the object/id bimap thread-safe is a problem. The synchronization you put in is not sufficient. In particular, it is not safe to call labelToId.get(object) while a concurrent labelToId.put(object, id) is happening. It is not guaranteed that the get() will see the state either before or after the put(). It might see something else (looking at the source code of TObjectIntHashMap).

I think it might be ok to just synchronize every access to the bimap. I'll go over it again.

[tpietzsch]

I revised it a bit, and synchronizing every access to the bimap doesn't seem to make a difference. Neither for LabelingBenchmark nor for the use case in metaseg.