README.md in faster_path-0.1.0 vs README.md in faster_path-0.1.1

- old
+ new

@@ -1,24 +1,21 @@ # FasterPath [![Gem Version](https://badge.fury.io/rb/faster_path.svg)](https://badge.fury.io/rb/faster_path) [![Build Status](https://travis-ci.org/danielpclark/faster_path.svg?branch=master)](https://travis-ci.org/danielpclark/faster_path) [![Tweet This](https://raw.githubusercontent.com/danielpclark/faster_path/master/assets/tweet.png)](https://twitter.com/share?url=https%3A%2F%2Fgithub.com%2Fdanielpclark%2Ffaster_path&via=6ftdan&hashtags=Ruby&text=You%20could%20save%2015%25%20or%20more%20on%20website%20load%20time%20by%20switching%20to%20the%20FasterPath%20gem.) -#### As of gem version 0.0.9 this shaves off 66% of my Rails applications load time. +#### As of gem version 0.0.9 this shaves off 66% of my Rails applications page load time. The primary **GOAL** of this project is to improve performance in the most heavily used areas of Ruby as path relation and file lookup is currently a huge bottleneck in performance. As this is the case the path performance updates will likely not be limited to just changing the Pathname class but also will be offering changes in related methods and classes. Users will have the option to write their apps directly for this library, or they can choose to either refine or monkeypatch the existing standard library. Refinements are narrowed to scope and monkeypatching will be a sledge hammer ;-) -**NOTE**: Refinements and monkeypatch methods are highly likely to be changed and renamed pre version -0.1.0 so keep that in mind! - ## Why I did a check on Rails on what methods were being called the most and where the application spend most of its time. It turns out roughly 80% _(as far as I can tell)_ of the time spent and calls made are file Path handling. This is shocking, but it only gets worse when handling assets. **That is @@ -68,10 +65,10 @@ ``` Add this line to your application's Gemfile: ```ruby -gem 'faster_path' +gem 'faster_path', '~> 0.1.0' ``` And then execute: $ bundle