Could you expand a bit on the differences between CHAMPs and HAMTs? Most of the info I see about CHAMPs makes them seem very similar, but with a slightly different node structure.
We introduce CHAMP (Compressed Hash-Array Mapped Prefix-tree), an evolutionary improvement over HAMTs. The new design increases the overall performance of immutable sets and maps. Furthermore, its resulting general purpose design increases cache locality and features a canonical representation."
If you just want to know the difference between CHAMP and HAMT, then Google gets you that information pretty swiftly. Maybe you were looking for https://blog.acolyer.org/2015/11/27/hamt which discusses HAMT and then discusses the improvements CHAMP brings to the table.
It doesn't make it a bad thesis, but also doesn't answer the questions asked, which is presumably why they were asked.
You can also have a look at the JVMLS'16 talk (https://www.youtube.com/watch?v=pUXeNAeyY34) for a high-level overview of the work that is covered in my thesis.
Let's say that I were to use a vector of coordinates as the key to something in a map. Would CHAMP still vastly outperform HAMT?
To answer your questions about using vectors of coordinates of keys: it depends on the design implementation of the vector's hash code, regardless if you use HAMT or CHAMP.
Using collections as keys in other collections is in general a performance sensitive subject. The available HAMT implementations in Clojure and Scala fail to deliver here. The case study in Chapter 3.7 nests hash-sets into hash-sets (i.e., Set.Immutable<Set.Immutable<K>> sets). The CHAMP implementation yields minimal speedups of ~10x over Clojure and Scala due to the way it calculates and incrementally updates the collection's hash code.
All the children are "compressed" into a single array. To be able to index a child quickly, it suffices to count the number of bit set below the bit corresponding to the child (something that can be done with some masking and a intrinsic bit count operation that maps to an ASM instruction).
This is a bit simplified. In reality each node distinguishes between its children that are actual key-value map entries and those that are nodes.
Additionally, entries are not stored in an extra "Entry" object, but instead occupy two slot in the storage array.
Nevertheless that is your principle: each node is sparse and only allocates storage for the children that are actually present (at the cost of maintaining two bitmaps: one for children entries and one for children nodes).
This is in particular the case when compared to Clojure's PersistentHashMap. Clojure reserves two array slots per entry to either store a) two pointers inline (i.e., key and value tuple), or b) a single reference to a sub-trie in the second slot. At runtime Clojure checks if the first slot is equal to 'null' for distinguishing cases a)/b) and doing the correct type casts at runtime. The thesis visualizes this in chapter 3, page 42.