summaryrefslogtreecommitdiff
path: root/t/t0011-hashmap.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-07-31t: sort output of hashmap iterationLibravatar Jeff King1-22/+36
The iteration order of a hashmap is undefined, and may depend on things like the exact set of items added, or the table has been grown or shrunk. In the case of an oidmap, it even depends on endianness, because we take the oid hash by casting sha1 bytes directly into an unsigned int. Let's sort the test-tool output from any hash iterators. In the case of t0011, this is just future-proofing. But for t0016, it actually fixes a reported failure on the big-endian s390 and nonstop ports. I didn't bother to teach the helper functions to optionally sort output. They are short enough that it's simpler to just repeat them inline for the iteration tests than it is to add a --sort option. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-17test-hashmap: remove 'hash' commandLibravatar Christian Couder1-9/+0
If hashes like strhash() are updated, for example to use a different hash algorithm, we should not have to be updating t0011 to change out the hashes. As long as hashmap can store and retrieve values, and that it performs well, we should not care what are the values of the hashes. Let's just focus on the externally visible behavior instead. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-27t/helper: merge test-hashmap into test-toolLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-07hashmap: add string interning APILibravatar Karsten Blees1-0/+13
Interning short strings with high probability of duplicates can reduce the memory footprint and speed up comparisons. Add strintern() and memintern() APIs that use a hashmap to manage the pool of unique, interned strings. Note: strintern(getenv()) could be used to sanitize git's use of getenv(), in case we ever encounter a platform where a call to getenv() invalidates previous getenv() results (which is allowed by POSIX). Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18add a hashtable implementation that supports O(1) removalLibravatar Karsten Blees1-0/+240
The existing hashtable implementation (in hash.[ch]) uses open addressing (i.e. resolve hash collisions by distributing entries across the table). Thus, removal is difficult to implement with less than O(n) complexity. Resolving collisions of entries with identical hashes (e.g. via chaining) is left to the client code. Add a hashtable implementation that supports O(1) removal and is slightly easier to use due to builtin entry chaining. Supports all basic operations init, free, get, add, remove and iteration. Also includes ready-to-use hash functions based on the public domain FNV-1 algorithm (http://www.isthe.com/chongo/tech/comp/fnv). The per-entry data structure (hashmap_entry) is piggybacked in front of the client's data structure to save memory. See test-hashmap.c for usage examples. The hashtable is resized by a factor of four when 80% full. With these settings, average memory consumption is about 2/3 of hash.[ch], and insertion is about twice as fast due to less frequent resizing. Lookups are also slightly faster, because entries are strictly confined to their bucket (i.e. no data of other buckets needs to be traversed). Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>