diff --git a/README.md b/README.md
index 364e6d43..dfc94252 100644
--- a/README.md
+++ b/README.md
@@ -1,15 +1,16 @@
 # marked
 
-A full-featured markdown parser and compiler implemented in ~430 lines of JS.  
+A full-featured markdown parser and compiler implemented in ~430 lines of JS.
 Built for speed.
 
 ## Benchmarks
 
 ``` bash
 $ node test --bench
-marked completed in 15051ms.
-showdown completed in 28267ms. 
-markdown-js completed in 70732ms.
+marked completed in 12071ms.
+showdown (reuse converter) completed in 27387ms.
+showdown (new converter) completed in 75617ms.
+markdown-js completed in 70069ms.
 ```
 
 ## Install
@@ -20,19 +21,19 @@ $ npm install marked
 
 # Another javascript markdown parser
 
-The point of marked was to create a markdown compiler where it was possible to 
-frequently parse huge chunks of markdown without having to worry about 
+The point of marked was to create a markdown compiler where it was possible to
+frequently parse huge chunks of markdown without having to worry about
 caching the compiled output somehow...or blocking for an unnecesarily long time.
 
-marked lingers around 430 (may vary) lines long and still implements all 
+marked lingers around 430 (may vary) lines long and still implements all
 markdown features. It is also now fully compatible with the client-side.
 
-marked more or less passes the official markdown test suite in its 
-entirety. This is important because a surprising number of markdown compilers 
-cannot pass more than a few tests. It was very difficult to get marked as 
-compliant as it is. It could have cut corners in several areas for the sake 
-of performance, but did not in order to be exactly what you expect in terms 
-of a markdown rendering. In fact, this is why marked could be considered at a 
+marked more or less passes the official markdown test suite in its
+entirety. This is important because a surprising number of markdown compilers
+cannot pass more than a few tests. It was very difficult to get marked as
+compliant as it is. It could have cut corners in several areas for the sake
+of performance, but did not in order to be exactly what you expect in terms
+of a markdown rendering. In fact, this is why marked could be considered at a
 disadvantage in the benchmarks above.
 
 ## Usage
@@ -61,8 +62,8 @@ $ node
 ## Todo (& notes to self)
 
 - Implement GFM features.
-- Possibly add some 
-  [ReMarkable](http://camendesign.com/code/remarkable/documentation.html) 
+- Possibly add some
+  [ReMarkable](http://camendesign.com/code/remarkable/documentation.html)
   features while remaining backwardly compatible with all markdown syntax.
 - Optimize the lexer to return an iterator instead of a collection of tokens.
 - Add an explicit pretty printing and minification feature.
diff --git a/package.json b/package.json
index 9c6318f1..16899ade 100644
--- a/package.json
+++ b/package.json
@@ -2,7 +2,7 @@
   "name": "marked",
   "description": "A markdown parser built for speed",
   "author": "Christopher Jeffrey",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "main": "./lib/marked.js",
   "bin": { "marked": "./bin/marked" },
   "repository": "git://github.com/chjj/marked.git",