The thread_safe gem is being deprecated and all its code has been merged
into the concurrent-ruby gem. The new class, Concurrent::Map, is exactly
the same as its predecessor except for fixes to two bugs discovered
during the merge.

I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution?

To look at memory:

```ruby
require 'get_process_mem'

mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb

after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"

```

Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests.

To look at raw speed:

```ruby
require 'benchmark/ips'

number_of_objects_reduced = 1_114

Benchmark.ips do |x|
  x.report("freeze")    { number_of_objects_reduced.times { " ".freeze } }
  x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end
```

We get the results

```
Calculating -------------------------------------
              freeze     1.428k i/100ms
           no-freeze   609.000  i/100ms
-------------------------------------------------
              freeze     14.363k (± 8.5%) i/s -     71.400k
           no-freeze      6.084k (± 8.1%) i/s -     30.450k
```

Now we can do some maths:

```ruby
ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration 

ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration 

diff = call_time_before - call_time_after

number_of_objects_reduced * diff * 100

# => 0.4530373333993266 miliseconds saved per request
```

So we're shaving off 1 second of execution time for every 220 requests. 

Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep. 

p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings. 

Keep those strings Frozen

![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)

Various grammar corrections and wrap to 80 characters.

LookupContext is class name

Given the following templates:

    mailer/demo.html.erb
    mailer/demo.en.html.erb
    mailer/demo.pt.html.erb

Before this change for a locale that doesn't have its related file
the `mailer/demo.html.erb` will
be rendered even if `en` is the default locale.

Now `mailer/demo.en.html.erb` has precedence over the file without
 locale.

Also, it is possible to give a fallback.

    mailer/demo.pt.html.erb
    mailer/demo.pt-BR.html.erb

So if the locale is `pt-PT`, `mailer/demo.pt.html.erb` will be
 rendered given the right I18n fallback configuration.

Fixes #11884.

The performance is almost the same with both implementations but this is
clear.

Before this patch:

Calculating -------------------------------------
  small erb template      1452 i/100ms
-------------------------------------------------
  small erb template    17462.1 (±13.3%) i/s -      85668 in   5.031395s
.Calculating -------------------------------------
small erb template with 1 partial
                           887 i/100ms
-------------------------------------------------
small erb template with 1 partial
                         8899.6 (±18.8%) i/s -      42576 in   5.009453s
.Calculating -------------------------------------
small erb template with 2 partials
                           666 i/100ms
-------------------------------------------------
small erb template with 2 partials
                         6821.5 (±8.8%) i/s -      33966 in   5.020791s

After the patch:

Calculating -------------------------------------
  small erb template      1479 i/100ms
-------------------------------------------------
  small erb template    15956.6 (±7.6%) i/s -      79866 in   5.036001s
.Calculating -------------------------------------
small erb template with 1 partial
                           841 i/100ms
-------------------------------------------------
small erb template with 1 partial
                         9242.2 (±6.9%) i/s -      46255 in   5.029497s
.Calculating -------------------------------------
small erb template with 2 partials
                           615 i/100ms
-------------------------------------------------
small erb template with 2 partials
                         6524.7 (±6.8%) i/s -      32595 in   5.020456s

You can find the benchmark code at
https://gist.github.com/rafaelfranca/dee31120cfdb1ddc3b56

Using ruby-prof, I noticed that Set#add had the largest 'self time'
percentage (5% of the overall time spent rendering) when
benchmarking the rendering of a small cached ERB template that was 3
lines long. It turns out it was from this line. I don't believe the
Set is necessary, either. Removing this line increases the rendering
ips using Benchmark::ips accordingly.

Before we had a bug in the resolver cache so the disable_cache were not
working when passing options to find

LookupContext is eagerly loaded, and FallbackFileSystemResolver is
referenced at the class level.  Just require the resolver from the
eagerly loaded class rather than jumping through autoload hoops

By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:

  app/views/projects/show.html.erb
  app/views/projects/show.html+tablet.erb
  app/views/projects/show.html+phone.erb

If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.

In the controller, we can also tailer to the variants with this syntax:

  class ProjectsController < ActionController::Base
    def show
      respond_to do |format|
        format.html do |html|
          @stars = @project.stars

          html.tablet { @notifications = @project.notifications }
          html.phone  { @chat_heads    = @project.chat_heads }
        end

        format.js
        format.atom
      end
    end
  end

The variant itself is nil by default, but can be set in before filters, like
so:

  class ApplicationController < ActionController::Base
    before_action do
      if request.user_agent =~ /iPad/
        request.variant = :tablet
      end
    end
  end

This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.

CVE-2013-6414

Summary of the changes:
 * Add thread_safe gem.
 * Use thread safe cache for digestor caching.
 * Replace manual synchronization with ThreadSafe::Cache in Relation::Delegation.
 * Replace @attribute_method_matchers_cache Hash with ThreadSafe::Cache.
 * Use TS::Cache to avoid the synchronisation overhead on listener retrieval.
 * Replace synchronisation with TS::Cache usage.
 * Use a preallocated array for performance/memory reasons.
 * Update the controllers cache to the new AS::Dependencies::ClassCache API.
   The original @controllers cache no longer makes much sense after @tenderlove's
   changes in 7b6bfe84 and f345e238.
 * Use TS::Cache in the connection pool to avoid locking overhead.
 * Use TS::Cache in ConnectionHandler.

default_formats array is used by LookupContext in order to allow
rendering templates when :formats option is not passed. Previously it
was always set to Mime::SET, which created dependency on Action Pack. In
order to remove this dependency, Mime::SET is used only if
ActionController is loaded.

Closes #5025 part 2

For example, calling hello.erb is now deprecated. Since Rails 3.0
passing the handler had no effect whatsover. This commit simply
deprecates such cases so we can clean up the code in later releases.