Address Guillaume and Olaf reviews. Also fix a wrong number.

Author: julienrf

blog/_posts/2018-02-07-collections-performance.md

@@ -24,18 +24,18 @@ For reference, the source code of the new collections is available in
 
 ## Overhead Of View Based Implementations
 
-Let’s be clear: the view based implementations are in general slower than their
+Let’s be clear, the view based implementations are in general slower than their
 builder based versions. How much slower exactly varies with the type of collection
 (e.g. `List`, `Vector`, `Set`), the operation (e.g. `map`, `flatMap`, `filter`)
 and the number of elements in the collection. In my benchmark on `Vector`, on
-the `map`, `filter` and `flatMap` operations, with 1 element to 7 million of
+the `map`, `filter` and `flatMap` operations, with 1 to 7 million of
 elements, I measured an average slowdown of 25%.
 
 ## How To Fix That Performance Regression?
 
 Our solution is simply to go back to builder based implementations for strict collections: we
 override the default view based implementations with more efficient builder based
-ones. We actually and up with the same implementations as in the old collections.
+ones. We actually end up with the same implementations as in the old collections.
 
 In practice these implementations are factored out in traits that can be mixed
 into concrete collection types. Such trait names are always prefixed with
@@ -70,8 +70,8 @@ for `Seq` collections.
 
 ## Is The View Based Design Worth It?
 
-In my previous article I explained that a drawback of the old builder based design was that,
-on non strict collections (e.g. `Stream` or `View`), we had to carefully override all the
+In my previous article, I explained a drawback of the old builder based design.
+On non strict collections (e.g. `Stream` or `View`), we had to carefully override all the
 default implementations of transformation operations to make them non strict.
 
 Now it seems that the situation is just reversed: the default implementations work well
@@ -86,15 +86,15 @@ by Stefan Zeiger [here](https://www.reddit.com/r/scala/comments/7g52cy/let_them_
 > implementation for a strict collection type you only suffer a small performance
 > impact but it's still correct.
 
-In short: implementations are **correct first** in the new design but you might want to
+In short, implementations are **correct first** in the new design but you might want to
 override them for performance reasons on strict collections.
 
 ## Performance Comparison With 2.12’s Collections
 
 Talking about performance, how performant are the new collections compared to the old ones?
 
 Again, the answer depends on the type of collection, the operations and the number of elements.
-My `Vector` benchmarks show a 20% speedup on average:
+My `Vector` benchmarks show a 35% speedup on average:
 
 ![](/resources/img/new-collections-performance-filter.png)
 
@@ -104,26 +104,29 @@ My `Vector` benchmarks show a 20% speedup on average:
 
 These charts show the execution time (vertically) of the `filter`, `map` and `flatMap`
 operations, according to the number of elements (horizontally). Note that scales are
-logarithmic in both axis. The blue line shows the performance of the old `Vector`,
+logarithmic in both axes. The blue line shows the performance of the old `Vector`,
 the green line shows the performance of the new `Vector` if it used only view based
 implementations, and the red line shows the actual performance of the new `Vector`
 (with strict optimized implementations). Benchmark source code and numbers can be found
 [here](https://gist.github.com/julienrf/f1cb2b062cd9783a35e2f35778959c76).
 
 Since operation implementations end up being the same, why do we get better performance
-at all? Well, these numbers are specific to `Vector`, and are due to the fact that
-we more agressively inlined a few critical methods. I don’t expect the new collections
-to be *always* 20% faster than the old collections. However, there is no reason for
+at all? Well, these numbers are specific to `Vector` and the tested operations, they
+are due to the fact that
+we more aggressively inlined a few critical methods. I don’t expect the new collections
+to be *always* faster than the old collections. However, there is no reason for
 them to be slower since the execution path, when calling an operation, can be made
 exactly the same as in the old collections.
 
 ## Conclusion
 
 This article studied the performance of the new collections. I’ve reported that view
-based operation implementations are about 25% slower than builder based implementations
+based operation implementations are about 25% slower than builder based implementations,
 and I’ve explained how we restored builder based implementations on strict collections.
+Last but not least, I’ve shown that defaulting to the view based implementations does
+make sense for the sake of correctness.
 
-I expect the new collections to be as fast or slightly faster than the previous collections.
+I expect the new collections to be equally fast or slightly faster than the previous collections.
 Indeed, we took advantage of the rewrite to apply some more optimizations here and
 again.
 
@@ -133,4 +136,4 @@ data structures. For instance, we recently
 a completely new implementation of immutable `Set` and `Map` based on [compressed
 hash-array mapped prefix-trees](https://michael.steindorfer.name/publications/oopsla15.pdf).
 This data structure has a smaller memory footprint than the old `HashSet` and `HashMap`,
-and some operations are an order of magnitude faster.
+and some operations can be an order of magnitude faster (e.g. `==` is up to 7x faster).