| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| | |
`render` is the only possible source for the `plain` option. Pulling
the conditional up to the `render` method removes far away conditionals
|
| |
| |
| |
| |
| |
| | |
We don't need to pass the full hash just to pull one value out. It's
better to just pass the value that the method needs to know about so
that we can abstract it away from "options"
|
| |
| |
| |
| |
| |
| | |
Since all controller instances are required to have a request and
response object, RackDelegation is no longer needed (we always have to
delegate to the response)
|
| |
| |
| |
| |
| | |
the subclass sets the body on the response object, so we don't need the
superclass doing it too
|
| |
| |
| |
| |
| |
| | |
Now that `Controller#status=` just delegates to the response object,
we don't need to set the response on the controller and the response.
We can just set it in one place.
|
| |
| |
| |
| | |
we always have a response object, so there is no reason to test it
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Controllers should always have a request and response when responding.
Since we make this The Rule(tm), then controllers don't need to be
somewhere in limbo between "asking a response object for a rack
response" or "I, myself contain a rack response". This duality leads to
conditionals spread through the codebase that we can delete:
* https://github.com/rails/rails/blob/85a78d9358aa728298cd020cdc842b55c16f9549/actionpack/lib/action_controller/metal.rb#L221-L223
|
| | |
|
| |
| |
| |
| |
| |
| | |
we don't need an instance to figure out what type of response to
allocate. Later we'll pull this up the stack and pass the response
object down
|
|\ \
| | |
| | | |
Remove unused block arguments
|
| | | |
|
|/ /
| |
| |
| | |
May be missed in 5fe141638f1243ac6ae187ae14aa398b4c1875a2 commit
Also fixes the broken build
|
| | |
|
|\ \
| | |
| | | |
Authorization scheme should be case insensitive. Fixes #21199
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
people should be accessing request information through the request
object, not via the env hash. If they really really want at the env
hash, then they can get it off the request.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The cookie jar can just ask the request object for the information it
needs. This allows us to stop allocating hashes for options, and also
allows us to delay calculating values in advance. Generating the
options hash forced us to calculate values that we may never have needed
at runtime
|
|/ /
| |
| |
| |
| |
| | |
Accessing a request object has nice advantages over accessing a hash.
If you use a missing method name, you'll get an exception rather than a
`nil` (is one nice feature)
|
| |
| |
| |
| |
| |
| | |
The request.script_name is dup-d which allocates an extra string. It is most commonly an empty string "". We can save a ton of string allocations by checking first if the string is empty, if so we can use a frozen empty string instead of duplicating an empty string.
This change buys us 35,714 bytes of memory and 893 fewer objects per request.
|
|\ \
| | |
| | | |
Fix params_wrapper doc [ci skip]
|
| | |
| | |
| | |
| | |
| | |
| | | |
This feature also works with `PUT`, `PATCH` and `DELETE` requests.
Also developers can add `:url_encoded_form` and `:multipart_form`
into the `:format` for wrapping url encoded or multipart form data.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| | |
there is no reason to `convert_hashes_to_parameters` with an assignemt
flag. The caller knows whether or not it wants the value assigned. We
should just change the uncommon case (not writing to the underlying
hash) to just call the conversion method and return that value.
|
| |
| |
| |
| |
| |
| | |
only hashes are converted to parameter objects, so lets add a branch for
them. This also removes a is_a? test for Parameters so we can be
abstracted from the class.
|
|\ \
| | |
| | | |
Freeze string literals when not mutated.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
|\ \ \
| |/ /
|/| | |
Fix exception overwritten for parameters fetch method
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When executing an `ActionController::Parameters#fetch` with a block
that raises a `KeyError` the raised `KeyError` will be rescued and
converted to an `ActionController::ParameterMissing` exception,
covering up the original exception.
[Jonas Schubert Erlandsson & Roque Pinel]
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will silence deprecation warnings.
Most of the test can be changed from `render :text` to render `:plain`
or `render :body` right away. However, there are some tests that needed
to be fixed by hand as they actually assert the default Content-Type
returned from `render :body`.
|
|\ \
| | |
| | | |
Add deprecation warning for `render :text`
|
| | |
| | |
| | |
| | |
| | |
| | | |
We've started on discouraging the usage of `render :text` in #12374.
This is a follow-up commit to make sure that we print out the
deprecation warning.
|
| | |
| | |
| | |
| | |
| | | |
this way we don't need to call `to_unsafe_h` to get access to ask
questions about the underlying hash
|
| | |
| | |
| | |
| | | |
now `hash_filter` doesn't need to know about the `Parameters` class
|
| | |
| | |
| | |
| | |
| | | |
Since we proved that `element` is always of type `Parameter`, we know
that it will always respond to `permit`, so lets remove this conditional
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`element` can never be a hash because:
1. `slice` returns a Parameters object and calls each on it: https://github.com/rails/rails/blob/cb3f25593b1137e344086364d4b1a52c08e8eb3b/actionpack/lib/action_controller/metal/strong_parameters.rb#L656
2. `each` which is implemented by `each_pair` will call `convert_hashes_to_parameters` on the value: https://github.com/rails/rails/blob/cb3f25593b1137e344086364d4b1a52c08e8eb3b/actionpack/lib/action_controller/metal/strong_parameters.rb#L192-197
3. `convert_hashes_to_parameters` will convert any hash objects in to parameters objects: https://github.com/rails/rails/blob/cb3f25593b1137e344086364d4b1a52c08e8eb3b/actionpack/lib/action_controller/metal/strong_parameters.rb#L550-566
|
| | |
| | |
| | |
| | |
| | |
| | | |
Now that the value is cached on the stack,
`array_of_permitted_scalars_filter` is exactly the same as
`array_of_permitted_scalars?`, so lets just have one
|
| | |
| | |
| | |
| | |
| | |
| | | |
this way the method doesn't have to know what the new params object is,
it just yields to a block. This change also caches the value of
`self[key]` on the stack
|
|/ /
| |
| |
| |
| |
| | |
We should disconnect `array_of_permitted_scalars_filter` from the
instance so that we can make hash filtering functional. For now, pull
the conditional up out of that method
|
| |
| |
| |
| |
| |
| | |
`ActionController::Parameters#to_h` returns a hash, so lets have
`ActionController::Parameters#to_unsafe_h` return a hash instead of
an `ActiveSupport::HashWithIndifferentAccess` for consistency.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is another take at #14384 as we decided to wait until `master` is
targeting Rails 5.0. This commit is implementation-complete, as it
guarantees that all the public methods on the hash-inherited Parameters
are still working (based on test case). We can decide to follow-up later
if we want to remove some methods out from Parameters.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Allow default_render to take a block to customize behavior when there's no template
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In 0de4a23 the behavior when there is a missing template was changed to
not raise an error, but instead head :no_content. This is a breaking
change and some gems rely on this happening.
To allow gems and other code to work around this, allow
`default_render` to take a block which, if provided, will
execute the contents of that block instead of doing the `head :no_content`.
|