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