LinkedHash(Map|Set) have weird complexity #2727
Comments
While writing up vavr-io#2727 I noticed that `LinkedHashSet.head()` is implemented `iterator().head()`. This is inefficient because `queue.iterator().next()` makes a call to `.head()`, but also to `.tail()` so as to prepare for the next `head()` call. Given the structure of the underlying `Queue`, the `head()` call is worst case `O(1)` but the tail call is worst case `O(n)`. The present worst case will be achieved if there have never been overwrites or removals from the set, which is probably a fairly common case.
While writing up #2727 I noticed that `LinkedHashSet.head()` is implemented `iterator().head()`. This is inefficient because `queue.iterator().next()` makes a call to `.head()`, but also to `.tail()` so as to prepare for the next `head()` call. Given the structure of the underlying `Queue`, the `head()` call is worst case `O(1)` but the tail call is worst case `O(n)`. The present worst case will be achieved if there have never been overwrites or removals from the set, which is probably a fairly common case.
|
I made a draft implementation of a CHAMP-trie based VAVR-collection, that performs all operations in constant time. |
|
My pull-request 2745 is supposed to address this problem for LinkedHashSet and LinkedHashMap. |
While writing up #2727 I noticed that `LinkedHashSet.head()` is implemented `iterator().head()`. This is inefficient because `queue.iterator().next()` makes a call to `.head()`, but also to `.tail()` so as to prepare for the next `head()` call. Given the structure of the underlying `Queue`, the `head()` call is worst case `O(1)` but the tail call is worst case `O(n)`. The present worst case will be achieved if there have never been overwrites or removals from the set, which is probably a fairly common case.
|
I have made now a release that is binary compatible with vavr 0.10.5, but which is implemented with CHAMP-based collections. You can get it here: https://github.com/wrandelshofer/vavr/releases/tag/v0.10.5 |
|
I hit this issue (presumably) today and reported it by email. FWIW, here's a copy of what I found. I have been experimenting with VAVR collections with a view to replacing our (*) current HashTrie implementation (due to Michael Froh) with a map implementation that maintains ordering. I constructed a use case that generates a word frequency from a Shakespeare corpus - 900K tokens, of which about 66K are distinct, so the dominant operation is LinkedHashMap.put() replacing an existing entry with an updated value. This gets progressively slower as the task progresses. Profiling suggests that the dominant factor is calls on io.vavr.collections.List.replace(). It's also spending a lot of time in my equals() method comparing keys. The number of calls on my equals() method seems excessive: Between put() call 199001 (with map size 25612) and put() call 200001 (at size 25724) there are around 20 million calls on my equals() method. Total elapsed time is something like 25min compared with 6s for the current unordered map implementation. (*) "our" here means the implementation in the Saxon XSLT/XQuery processor |
|
@michaelhkay Ideally, you can swap out the file vavr.jar with vavr-champ-0.10.5.jar that I have published here: |
|
Yes, that's next on my list. After redecorating my study. |
|
Generally, the classic implementation of persistent/immutable data structures has... suboptimal performance characteristics. Going CHAMP (Compressed Hash-Array Mapped Prefix-tree) is one of the ways to tackle it: Compressed Hash-Array Mapped Prefix-tree I would love to have this in 1.0.0 |
|
The code below runs in about 1.4 seconds with vavr-champ LinkedHashMap. package outside_of_vavr;
import io.vavr.collection.LinkedHashMap;
import io.vavr.collection.Map;
import io.vavr.control.Option;
import org.junit.jupiter.api.Test;
import java.util.ArrayList;
import java.util.UUID;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class ShakespeareCorpusTest {
/**
* This use case generates a word frequency from a
* simulated Shakespeare corpus - 900K tokens,
* of which about 66K are distinct,
* so the dominant operation is LinkedHashMap.put()
* replacing an existing entry with an updated value.
*/
@Test
public void shouldPerformReasonablyWell() {
// GIVEN the Shakespeare corpus
int distinctWords = 66_000;
int totalWords = 900_000;
java.util.List<String> corpus = new ArrayList<>(distinctWords);
for (int i = 0; i < distinctWords; i++) {
corpus.add(UUID.randomUUID().toString());
}
while (corpus.size() < totalWords) {
corpus.addAll(corpus.subList(0, Math.min(distinctWords, totalWords - corpus.size())));
}
java.util.Collections.shuffle(corpus);
System.out.println("corpus.size=" + corpus.size());
// WHEN generate a word frequency from the corpus
//Map<String, Integer> m = HashMap.empty();
Map<String, Integer> m = LinkedHashMap.empty();
for (String word : corpus) {
Option<Integer> frequency = m.get(word);
if (frequency.isEmpty()) {
m = m.put(word, 0);
} else {
m = m.put(word, frequency.get() + 1);
}
}
// THEN the size must match the expected size
assertEquals(distinctWords, m.size());
}
} |
|
Took a bit of an effort to work out how to change my gradle build to pick it up (not my build script...) but Wow! this certainly fixes the performance bug. Average execution time over 20 runs 710ms, Memory used: 1095Mb Previously, with the unordered HashTrie map from Michael Froh: 662ms, Memory 976Mb I wouldn't place much confidence in the memory measurements. The timings include the XML parsing cost. For the record, this is using the Shakespeare corpus at GitHub/PlayShakespeare.com-XML, and the Saxon XQuery 4.0 code is
producing the result (the number of occurrences of "the") of 24157. Each XML document in the collection is parsed in a separate thread but the query then executes in a single thread. |
|
Thank you for testing! 😀 The memory overhead for a sequenced (linked) map is expected to be higher than for an non-sequenced (non-linked) map. The memory overhead of a vavr-champ LinkedHashMap is about 50 bytes per element. |
Mostly leaving this as a note. LinkedHashMap and LinkedHashSet are, as implemented in the Java standard library, pretty cool structures. Map entries contain a doubly linked list to next and previous elements, and because of the mutability, the cost of maintaining the list structure is always O(1). Effectively, you have a structure which can be treated as both a list and a set without the downsides in most practical cases.
In Vavr, these structures are implemented as a pair of a HashMap and a Queue. This pairing is rather uncool, because the complexity of various map operations becomes case-dependent.
For example (all complexities are listed as complexities on the queue, not on the paired HashMap):
When doing a put, if the element does not exist, the put is O(1). However, doing a put on an element that exists already is O(n) because the element's node is replaced in the queue (and I think the entire queue is copied at this time).
Likewise, doing a remove is O(n) because the queue must be rewritten.
The queue is stored as a head and tail with the tail possibly being reversed on dequeue. However, this is only amortized efficient when the reading operation actually dequeues (e.g. n enqs followed by n deqs will do one queue reversal, but n enqs followed by n iterations through the queue will do n queue reversals).
In practice this means that the datastructure is genuinely much less effective than the normal HashMap - one converting their HashMap into a LinkedHashMap should expect a huge performance degradation which is unexpected to one coming from normal Java maps.
An implementation with perhaps slightly poorer top-end performance but that would have much more forgiving worst case performance might be to do something more like:
This structure would be O(logn) on all operations, and generally avoid the sharp edges of the current structure. It would use quite a bit more memory, although this could be minimized by e.g. avoiding boxing of longs or at least sharing them. Of course, it's possible that top-end performance would suffer, especially since inserting in sorted order is the worst case for a red-black tree.
The text was updated successfully, but these errors were encountered: