| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Conceptually revert #20276
The feature was implemented for the `responders` gem. In the end,
they did not need that feature, and have found a better fix (see
plataformatec/responders#131).
`ImplicitRender` is the place where Rails specifies our default
policies for the case where the user did not explicitly tell us
what to render, essentially describing a set of heuristics. If
the gem (or the user) knows exactly what they want, they could
just perform the correct `render` to avoid falling through to
here, as `responders` did (the user called `respond_with`).
Reverting the patch allows us to avoid exploding the complexity
and defining “the fallback for a fallback” policies.
2. `respond_to` and templates are considered exhaustive enumerations
If the user specified a list of formats/variants in a `respond_to`
block, anything that is not explicitly included should result
in an `UnknownFormat` error (which is then caught upstream to
mean “406 Not Acceptable” by default). This is already how it
works before this commit.
Same goes for templates – if the user defined a set of templates
(usually in the file system), that set is now considered exhaustive,
which means that “missing” templates are considered `UnknownFormat`
errors (406).
3. To keep API endpoints simple, the implicit render behavior for
actions with no templates defined at all (regardless of formats,
locales, variants, etc) are defaulted to “204 No Content”. This
is a strictly narrower version of the feature landed in #19036 and
#19377.
4. To avoid confusion when interacting in the browser, these actions
will raise an `UnknownFormat` error for “interactive” requests
instead. (The precise definition of “interactive” requests might
change – the spirit here is to give helpful messages and avoid
confusions.)
Closes #20666, #23062, #23077, #23564
[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This moves digest calculation cache on to the details key object.
Before, the digest cache was a class level ivar, and one of the keys was
the hash value of the details key object:
https://github.com/rails/rails/blob/13c4cc3b5aea02716b7459c0da641438077f5236/actionview/lib/action_view/digestor.rb#L28
An object's hash value is not unique, so it's possible for this cache
key to produce colliding keys with no resolution. This commit move
cache on to the details key object itself, so we know that the digests
are always unique per details key object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't think caching this method makes any difference on Ruby 2.0:
```
require 'benchmark/ips'
class Foo
alias :object_hash :hash
attr_reader :hash
def initialize
@hash = object_hash
end
end
class Bar
end
hash = {}
foo = Foo.new
bar = Bar.new
Benchmark.ips do |x|
x.report("foo") { hash[foo] }
x.report("bar") { hash[bar] }
x.report("foo.hash") { foo.hash }
x.report("bar.hash") { bar.hash }
end
__END__
[aaron@TC ruby (trunk)]$ ruby test.rb
Warming up --------------------------------------
foo 118.361k i/100ms
bar 118.637k i/100ms
Calculating -------------------------------------
foo 7.944M (± 3.1%) i/s - 39.769M
bar 7.931M (± 3.4%) i/s - 39.625M
[aaron@TC ruby (trunk)]$ ruby test.rb
Warming up --------------------------------------
foo 122.180k i/100ms
bar 120.492k i/100ms
foo.hash 123.397k i/100ms
bar.hash 119.312k i/100ms
Calculating -------------------------------------
foo 8.002M (± 4.2%) i/s - 39.953M
bar 8.037M (± 4.5%) i/s - 40.124M
foo.hash 8.819M (± 3.9%) i/s - 44.053M
bar.hash 7.856M (± 4.1%) i/s - 39.254M
```
|
| |
|
|
|
|
| |
This metaprogrammed method doesn't seem to be a bottleneck, so lets just
use a regular method so it's easier to understand. We can follow up
with more interesting techniques for cache manipulation soon.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 5-0-beta-sec:
bumping version
fix version update task to deal with .beta1.1
Eliminate instance level writers for class accessors
allow :file to be outside rails root, but anything else must be inside the rails view directory
Don't short-circuit reject_if proc
stop caching mime types globally
use secure string comparisons for basic auth username / password
|
| | |
| |
| |
| |
| |
| | |
rails view directory
CVE-2016-0752
|
| |/ |
|
| | |
|
| |\
| |
| | |
Removed unused parameter `options` for `register_detail` method
|
| | |
| |
| | |
This method is only called with name & block.
|
| |/
|
|
|
|
|
| |
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.
|
| |
|
|
| |
explicitely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
| |
finder object
|
| |
|
|
|
|
| |
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
|
| |
|
