CHG: Extend README.

Author: krisvanrens

README.md

@@ -12,11 +12,11 @@ Sometimes it can be beneficial to speedup pure function calls by using [memoizat
 
 The cache storage required for implementing such a speedup often is an associative container (i.e. a key/value store).
 Programming language standard libraries provide such containers, often implemented as a [hash table](https://en.wikipedia.org/wiki/Hash_table) or a [red-black tree](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree).
-These implementations are fine for performance, but do not actually cover all cases because of the lack of retention management
+These implementations are fine for performance, but do not actually cover all use cases because of the lack of retention management
 
 Suppose your input data covers the whole space that can be represented by a 64-bit integer.
-There probably is some (generally non-uniform) distribution with which the input values arrive, but it's possible that over time _all_ possible values pass by.
-Any cache without retention management will then grow to potentially enormous dimensions in memory which is undesirable.
+There probably is some (generally non-uniform) probability distribution with which the input values arrive, but it's statistically possible that over time _all_ possible values pass by.
+Any cache without retention management will then grow to potentially enormous dimensions in memory which is undesirable, especially in memory-constrained environments.
 
 The cache implemented in this library uses a FIFO-style sequential data storage with fixed size, pre-allocated memory.
 When the cache is full, the oldest item is evicted.
@@ -38,7 +38,7 @@ impl Process {
 Each single call to this function results in the resource costs of the calculation.
 We can add memoization to this function in two different ways:
 
-- Using `MemoCache::get_or_insert_with`,
+- Using `MemoCache::get_or_insert_with` (or `get_or_try_insert_with`),
 - Using `MemoCache::get` and `MemoCache::insert`.
 
 For each of the following examples: each call to `calculate` will first check if the input value is already in the cache.
@@ -62,7 +62,7 @@ impl Process {
 }
 ```
 
-For fallible insert functions, there's `get_or_try_insert_with`.
+For fallible insert functions, there's `get_or_try_insert_with` that returns a `Result`.
 
 ### Example B: `get` and `insert`
 
@@ -95,12 +95,26 @@ However, if the input data set size is greater than the cache size, elements wil
 In this scenario, the fixed size of the cache, and/or the retention management aspect of `MemoCache` must weigh against the loss in performance over a `HashTable`.
 Always analyze your input data and perform measurements to select the cache size / type you use.
 
+The current implementation of the cache is focused on simplicity, making it outperform a `HashTable` under the right circumstances.
+
 Run the included benchmarks using [criterion](https://crates.io/crates/criterion) by invoking: `cargo bench`
 
+## Implementation details
+
+This cache stores its key/value pairs in a fixed-size array.
+A slot in this array represents a key/value and is either empty or occupied.
+A cursor pointing to an array slot keeps track of the next slot to be overwritten.
+
+Movement of the cursor is linear and incremental always pointing to the next empty slot, or the oldest slot.
+When the cursor is at the end of the array it wraps around to the beginning, so any next insert will overwrite an already existing slot.
+
+The implementation of the cache makes no assumptions whatsoever about the input data probability distribution, keeping the cache clean and simple.
+
 ## TODO
 
-- Investigate potential advanced cache improvements (e.g. start [here](https://en.wikipedia.org/wiki/Cache_replacement_policies)).
+- Currently, the implementation focuses on simplicity and makes no assumptions about the data arrival probability distribution. However, this could potentially be very beneficial. Investigate cache performance improvements (e.g. start [here](https://en.wikipedia.org/wiki/Cache_replacement_policies)).
 - Perhaps add cursor motion policies based on estimated input data probability distributions (e.g. in the current implementation an often-seen input value will still be overwritten by cursor movement).
+- More detailed benchmarks w.r.t. insert / lookup performance.
 
 ## License