Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
iterates in the order, in which keys were inserted
*
*
* Performance characteristics:
*
*
put, putFirst, putLast: O(log₃₂ N) in an amortized sense, because we sometimes have to
* renumber the elements.
*
remove: O(log₃₂ N) in an amortized sense, because we sometimes have to renumber the elements.
*
containsKey: O(log₃₂ N)
*
toMutable: O(1) + O(log₃₂ N) distributed across subsequent updates in
* the mutable copy
*
clone: O(1)
*
iterator creation: O(log₃₂ N)
*
iterator.next: O(1)
*
getFirst, getLast: O(log₃₂ N)
*
*
* Implementation details:
*
* This map performs read and write operations of single elements in O(log N) time,
* and in O(log N) space, where N is the number of elements in the set.
*
* The CHAMP trie contains nodes that may be shared with other maps.
*
* If a write operation is performed on a node, then this set creates a
* copy of the node and of all parent nodes up to the root (copy-path-on-write).
* Since the CHAMP trie has a fixed maximal height, the cost is O(1).
*
* This map can create a mutable copy of itself in O(1) time and O(1) space
* using method {@link #toMutable()}. The mutable copy shares its nodes
* with this map, until it has gradually replaced the nodes with exclusively
* owned nodes.
*
* Insertion Order:
*
* This map uses a counter to keep track of the insertion order.
* It stores the current value of the counter in the sequence number
* field of each data entry. If the counter wraps around, it must renumber all
* sequence numbers.
*
* The renumbering is why the {@code add} and {@code remove} methods are O(1)
* only in an amortized sense.
*
* To support iteration, we use a Vector. The Vector has the same contents
* as the CHAMP trie. However, its elements are stored in insertion order.
*
* If an element is removed from the CHAMP trie that is not the first or the
* last element of the Vector, we replace its corresponding element in
* the Vector by a tombstone. If the element is at the start or end of the Vector,
* we remove the element and all its neighboring tombstones from the Vector.
*
* A tombstone can store the number of neighboring tombstones in ascending and in descending
* direction. We use these numbers to skip tombstones when we iterate over the vector.
* Since we only allow iteration in ascending or descending order from one of the ends of
* the vector, we do not need to keep the number of neighbors in all tombstones up to date.
* It is sufficient, if we update the neighbor with the lowest index and the one with the
* highest index.
*
* If the number of tombstones exceeds half of the size of the collection, we renumber all
* sequence numbers, and we create a new Vector.
*
* The immutable version of this set extends from the non-public class
* {@code ChampBitmapIndexNode}. This design safes 16 bytes for every instance,
* and reduces the number of redirections for finding an element in the
* collection by 1.
*
* References:
*
* For a similar design, see 'SimpleImmutableSequencedMap.scala'. Note, that this code is not a derivative
* of that code.
*
*
The Scala library. SimpleImmutableSequencedMap.scala. Copyright EPFL and Lightbend, Inc. Apache License 2.0.
*
* @param the key type
* @param the value type
*/
@SuppressWarnings("exports")
public class ChampVectorMap implements ImmutableSequencedMap, Serializable {
private static final ChampVectorMap EMPTY = new ChampVectorMap<>(
BitmapIndexedNode.emptyNode(), VectorList.of(), 0, 0);
@Serial
private static final long serialVersionUID = 0L;
final transient BitmapIndexedNode> root;
/**
* Offset of sequence numbers to vector indices.
*
*
vector index = sequence number + offset
*/
final int offset;
/**
* The size of the map.
*/
final int size;
/**
* In this vector we store the elements in the order in which they were inserted.
*/
final VectorList
