Update documentation

README.md

@@ -2,4 +2,4 @@ A coremod to save a few of these:
 <img src="https://upload.wikimedia.org/wikipedia/commons/d/da/KL_CoreMemory.jpg" width="400"/>  
 (Konstantin Lanzet, CC BY-SA 3.0 <http://creativecommons.org/licenses/by-sa/3.0/>, via Wikimedia Commons)
 
-I intend to PR these changes to Forge soon.
+I intend to PR these changes to Forge soon. For a description of the improvements implemented by this mod see [here](summary.md).

summary.md

@@ -2,6 +2,9 @@ This file tries to explain the changes done in FerriteCore, and how much memory
 The saved memory refers to a ForgeCraft 1 instance around 19th December 2020.
 
 ### Optionals in `PropertyValueCondition`
+This change is irrelevant with the last point, it is only included in this list for
+completeness.
+
 The vanilla implementation contains code along these lines:
 ```java
 Optional<T> opt = newlyCreatedOptional();
@@ -24,11 +27,8 @@ the `Optional`s can be GCd right away.
 Saved memory: 100 MB  
 CPU impact: zero or negative (one less pointer to follow)  
 Side: client  
-Patches: One small patch in `PropertyValueCondition`  
-Notes: The last point makes this change essentially unnecessary
 
 ### BlockState neighbors
-
 To implement `StateHolder#with` (mostly seen as `BlockState#with`) a state needs to be
 able to quickly find its "neighbor states". In vanilla this is implemented using a
 `Table<Property<?>, Comparable<?>, S>` for each state. In total these tables use about 600
@@ -42,8 +42,7 @@ multiplication and addition operations.
 Saved memory: Around 600 MB (the `FastMap`s are around 4 MB total)  
 CPU impact: hard to prove, but most likely near zero  
 Side: both  
-Patches: Practically complete replacement of `StateHolder#func_235899_a_` and a small
-patch in `StateHolder#with`  
+Mixin folder: `fastmap`  
 Notes: There is a chance that this is slower for blocks with a very high number of
 properties, as the property to be modified is found using a linear search. This could be
 improved by using a binary search (probably sorted by hash), but it is not clear that this
@@ -52,20 +51,19 @@ will ever be faster in practice.
 ### BlockState property storage
 Each blockstate stores its properties as an `ImmutableMap<Property<?>, Comparable<?>>`,
 which takes around 170 MB in total. Most operations do not actually require this map, they
-can be implemented with similar speed using the `FastMap` from the previous point.  
-There is one problematic exception: `getValues`. This is a simple getter for the property
-map in vanilla, if the map is no longer stored it needs to be created on the fly. The
-method returns an `ImmutableMap`, which can't be easily extended due to package-private
-methods. Otherwise it would be possible to return a `Map`-implementation that only
-requires a `FastMap` and the index in that `FastMap`. The cleanest approach to this would
-probably be a second version of `getValues` which returns such a custom map, and replacing
-calls to the old one where the performance is problematic (this is not yet implemented).
+can be implemented with similar speed using the `FastMap` from the previous point.  There
+is one problematic exception: `getValues`. This is a simple getter for the property map in
+vanilla, if the map is no longer stored it needs to be created on the fly. The method
+returns an `ImmutableMap`, which can't be easily extended due to package-private methods.
+Otherwise it would be possible to return a `Map`-implementation that only requires a
+`FastMap` and the index in that `FastMap`. The current approach to this is to implement a
+second version of `getValues` which returns such a custom map, and to replace calls to the
+old one with the new implementation where possible.
 
 Saved memory: Around 170 MB  
 CPU impact: unclear (see second paragraph)  
 Side: both  
-Patches: Relatively small patches in all methods using the private field
-`StateHolder#properties` (most methods in `StateHolder`)
+Mixin folder: `nopropertymap`  
 
 ### Multipart model predicate caching
 Each multipart model stores a number of predicates to determine which parts to show under
@@ -87,10 +85,4 @@ Saved memory: 300-400 MB (relative to the state after the first change, so 100 M
 compared to a "clean" instance)  
 CPU impact: Some impact in model loading (but less allocations), zero while playing  
 Side: client  
-Patches:
- - `PropertyValueCondition#makePropertyPredicate` (a few lines)
- - `PropertyValueCondition#getPredicate` (roughly one line)
- - `AndCondition#getPredicate` (close to full replacement)
- - `OrCondition#getPredicate` (same)
-Alternatively `Selector#getOrAndCondition` could be patched to return different
-`And/OrCondition` implementations.
+Mixin folder: `predicates`