minor readme changes + added links to benchmarks

README.md

@@ -101,7 +101,7 @@ const nope = Nope.New;
 const oldNope = Nope.Old();
 ```
 
-Note that `Old` will always allocate a new value while `New` _is_ a value (thus more efficient).
+Note that `Old` will always allocate a new value while `New` **is** a value (thus more efficient).
 
 For generics the syntax differs a little bit:
 
@@ -116,7 +116,7 @@ const Option = Union(t => ({
 const maybeNumber = Option.None<number>();
 ```
 
-Even though `None` is a function, but it _always_ returns the same value. It is just a syntax to "remember" the type it was constructed with;
+Even though `None` is a function, but it **always** returns the same value. It is just a syntax to "remember" the type it was constructed with;
 
 Speaking of generics...
 
@@ -218,7 +218,7 @@ console.log(PaymentMethod.Check(15566909));
 
 This is because union values are objects under the hood. The `k` element is the key and the `p` is the payload array. I decided not to expose that through typings but I might reconsider that in the future. You **cannot** use it for redux actions, however you can **safely use it for redux state**.
 
-Note that in version 2.0 it was a tuple. But benchmarks [TODO link] showed that object are more efficient (I have no idea why arrays cannot be jitted efficiently).
+Note that in version 2.0 it was a tuple. But [benchmarks](https://github.com/twop/ts-union/tree/master/benchmarks) showed that object are more efficient (I have no idea why arrays cannot be jitted efficiently).
 
 ### API
 
@@ -313,7 +313,7 @@ That's the whole API.
 
 ### Benchmarks
 
-You can find a more details here [TODO link]. Both `unionize` and `ts-union` are 1.2x -2x (ish?) times slower than handwritten discriminated unions: aka `{tag: 'num', n: number} | {tag: 'str', s: string}`. But the good news is that you don't have to write the boilerplate yourself, _and_ it is still blazing fast!
+You can find a more details [here](https://github.com/twop/ts-union/tree/master/benchmarks). Both `unionize` and `ts-union` are 1.2x -2x (ish?) times slower than handwritten discriminated unions: aka `{tag: 'num', n: number} | {tag: 'str', s: string}`. But the good news is that you don't have to write the boilerplate yourself, _and_ it is still blazing fast!
 
 ### Breaking changes from 2.0.1 -> 2.1
 

benchmarks/README.md

@@ -39,13 +39,13 @@ There are 4 benchmark categories:
 - Creation of a union value
 - Match union value to produce a string via inline object
 - Match union value to produce a string via cached functions
-- Map `Num` union value to produce a 'Str' value out of it
+- Map `Num` union value to produce a `Str` value out of it
 
 If you just want to see the numbers then scroll to the bottom :)
 
 ## Creation
 
-All of them need to provide constructors from a number. The idea is that we preallocate an array for all of them (to avoid any GC or array resizing), and then give an equal probability call one of constructors.
+All of them need to provide constructors from a number. The idea is that we preallocate an array for all of them (to avoid any GC or array resizing), and then with equal probability invoke one of the constructors.
 
 Note currently the number of elements is 2000000.
 
@@ -170,7 +170,7 @@ const toStr = U.match({
 
 ## Mapping
 
-The goal of this benchmark is to identify a `Num` case and convert it to 'Str' case by simply calling `(n:number)=>n.toString()`
+The goal of this benchmark is to identify a `Num` case and convert it to `Str` case by simply calling `(n:number)=>n.toString()`
 
 ### baseline
 
@@ -235,6 +235,6 @@ Mapping
 
 ## Conclusion
 
-Nothing beats handwritten switch case :) But both `unionize` and `ts-union` provided comparable performance with baseline when matching function is cached.
+Nothing beats handwritten switch case :) But both `unionize` and `ts-union` provided a comparable performance with baseline when a matching function is cached.
 
-Note that I got different results all the time even with 50 attempts. So think about these numbers as a very rough approximation. In the real world usecases the functions might not be even considered as "hot". Thus, in my opinion the performance of these libraries is "good enough" to use them without thinking too much about it.
+Note that I get different results all the time even with 50 attempts. So think about these numbers as a very rough approximation. In the real world usecases these functions might not even be considered as "hot". Thus, in my opinion the performance of these libraries is "good enough" to use them without thinking too much about it.