This issue outlines several possible improvements to the RealPointCollection design, originally noted by @ctrueden.
Preserve point order.DefaultWritableRealPointCollection does not preserve point order. Meaning, someone could create a RealPointCollection with a Collection of points and then retrieve an Iterable via points() with the points in a different order. Ideally, point order should be preserved.
Avoid small objects.DefaultWritableRealPointCollection is backed by a HashMap which hashes on Trove double lists, meaning there are many small objects. The purpose of this was to ensure that the hash is on point location, not object reference. It would be nice to hash on something else, possibly something like XOR of the point coordinates? XOR can't be used because point pairs like (1, 3) and (3, 1) would have the same hash.
Naive implementation of RealPointCollection.
All the current implementations of RealPointCollection are backed by a secondary data structure, which makes test(...) very efficient. However, it could be useful to have a "lighter-weight" RealPointCollection that isn't backed by an additional data structure for times when test(...) performance isn't critical (i.e. SciView).
Improve performance of addPoint(...) bounds update.
When calling addPoint(...) on DefaultWritableRealPointCollection, the bounds are updated by looping all points in the collection. However, this is very inefficient. The bounds can be updated by simply checking if the new point is smaller/larger than the current min/max.
Please let me know your thoughts on these suggested improvements. Also note, there have been some suggested improvements to RealPointCollection in #34 as well.
Hi!
This issue outlines several possible improvements to the RealPointCollection design, originally noted by @ctrueden.
Preserve point order. DefaultWritableRealPointCollection does not preserve point order. Meaning, someone could create a
RealPointCollection
with aCollection
of points and then retrieve anIterable
viapoints()
with the points in a different order. Ideally, point order should be preserved.Avoid small objects.
DefaultWritableRealPointCollection
is backed by aHashMap
which hashes on Trove double lists, meaning there are many small objects. The purpose of this was to ensure that the hash is on point location, not object reference. It would be nice to hash on something else, possibly something like XOR of the point coordinates? XOR can't be used because point pairs like (1, 3) and (3, 1) would have the same hash.Naive implementation of
RealPointCollection
. All the current implementations ofRealPointCollection
are backed by a secondary data structure, which makestest(...)
very efficient. However, it could be useful to have a "lighter-weight"RealPointCollection
that isn't backed by an additional data structure for times whentest(...)
performance isn't critical (i.e. SciView).Generalize
DefaultWritableRealPointCollection
constructor. DefaultWritableRealPointCollection#DefaultWritableRealPointCollection(java.util.Collection) takes aCollection<L>
as input which is limiting. Instead this constructor should be generalized to takeCollection<? extends L>
.Improve performance of
addPoint(...)
bounds update. When callingaddPoint(...)
onDefaultWritableRealPointCollection
, the bounds are updated by looping all points in the collection. However, this is very inefficient. The bounds can be updated by simply checking if the new point is smaller/larger than the current min/max.Please let me know your thoughts on these suggested improvements. Also note, there have been some suggested improvements to
RealPointCollection
in #34 as well.