Add further info to HEAD path - and link to it

docs/DESIGN.md

@@ -86,7 +86,7 @@ All Ledger Keys created for any type must be 4-tuples starting with the tag.  Ab
 
 The PUT path for new objects and object changes depends on the Bookie interacting with the Inker to ensure that the change has been persisted with the Journal, the Ledger is updated in batches after the PUT has been completed.
 
-The HEAD path needs the Bookie to look in his cache of recent Ledger changes, and if the change is not present consult with the Penciller.
+The [HEAD path](paths.md) needs the Bookie to look in his cache of recent Ledger changes, and if the change is not present consult with the Penciller.
 
 The GET path follows the HEAD path, but once the sequence number has been determined through the response from the Ledger the object itself is fetched from the journal via the Inker.
 
@@ -122,3 +122,7 @@ Three potential recovery strategies are supported to provide some flexibility fo
 
 
 
+n recovery the key changes will be recalculated by comparing the change with the current database state.
+
+
+

docs/PATHS.md

@@ -7,6 +7,12 @@ To fulfil a HEAD request, the request needs to take the following path:
 - Check each persisted Level of the merge tree, and if not found
 - Return not_found
 
+## TLDR
+
+There is a lot of activity involved in the HEAD path - but most of the activity is very quick and has minimal impact.  
+
+The biggest chunk of effort by far, spending about two-thirds of the CPU time is when a value is found within a SST file's block - and the block needs to be de-serialised (using binary_to_term), and the block (which is a 32 element list of Keys/Metadata) needs to be walked to the nth element to return the Key/Value.  This process takes around 300 microseconds in real world tests, but only 53 microseconds in local benchmark testing (possibly due to CPU cache effects).
+
 Each of these steps is now described in more detail.
 
 ## The Bookie's Ledger Cache