so many hash tables

Data-structure-survey.md

@@ -74,6 +74,10 @@ Priority queue
 
 Single-threaded.
 
+There's a min-heap in libuv, implemented as a binary tree. The
+standard algorithms (as in `isc/heap`) use an array which should have
+better performance.
+
 
 # `isc/ht`
 
@@ -133,6 +137,24 @@ Uses reserved identifiers for static functions, which is undefined
 behaviour.
 
 
+# `isc/symtab`
+
+Another hash table, with another hash function.
+
+## used by
+
+  * `isccfg/parser`
+  * `bind9/check`
+
+## notes
+
+Single-threaded.
+
+Ought to be unnecessary. Might be worth cleaning up as part of some
+general parser refactoring (`isc/lex` could probably be made faster
+using `re2c`).
+
+
 # `isc/taskpool`
 
 Like `isc/pool`, but specialized for tasks
@@ -150,3 +172,15 @@ like that was the plan when `isc/pool` was added).
 
 There appears to be a bug in `isc_taskpool_expand()` when it fails to
 create a new task: the existing taskpool will be left empty.
+
+
+# `isccc`
+
+This library (as a whole) is the control channel implementation used
+by `rndc` and `named`.
+
+It has implementations of LISP-style S-expressions and association lists
+https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
+
+There is yet another hash table in `isccc/symtab`, and `isccc/base64`
+is also redundant.