diff --git a/docs/Lazy-Sweeping.md b/docs/Lazy-Sweeping.md
index ceb0615d..bdd5bec6 100644
--- a/docs/Lazy-Sweeping.md
+++ b/docs/Lazy-Sweeping.md
@@ -2,11 +2,11 @@ One of the basic improvements to the mark-sweep algorithm suggested by the Garba
 
 With this approach instead of waiting until tracing is finished and having the collector thread sweep the entire heap at once, each thread will sweep its own heaps as part of the allcation. When no more free space is available to meet a request the allocator will check to see if there are unswept heap pages. If so, the next one will be selected, the mutator will sweep it to free up space, and the new page will be used for allocation. If insufficient space is available then a major collection is triggered.
 
-The main goal of this process is to improve performance:
+The main goal of this process is to improve performance through:
 
 - better locality - heap slots tend to be used after they are swept
 - thread-local data - there is no need to lock the heap for allocation or sweeping since both operations are now performed by each mutator thread
-- accorinding to the GC handbook, it reduces the algorithmic complexity of mark-sweep to be proportional to the size of the live data in the heap, similar to a copying collector
+- according to the GC handbook, lazy sweeping reduces the algorithmic complexity of mark-sweep to be proportional to the size of the live data in the heap, similar to a copying collector
 
 
 Older notes:
@@ -137,6 +137,7 @@ The existing GC tracked free space and would start a major GC once the amount of
 # Results
 
 TODO: compare performance of new GC to old one, perhaps with benchmarks (compare 0.8.1 release with current 0.9 branch)
+Graph benchmarks in the google docs spreadsheet
 
 # Conclusion