| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| | |
We don't want to directly access the env hash
|
| |
| |
| |
| |
| | |
I want to implement this with something besides `@env` in the future, so
lets stop directly referencing it.
|
| |
| |
| |
| |
| | |
This commit allows us to use one request object rather than allocating
multiple request objects to deal with the session.
|
| |
| |
| |
| |
| | |
We're going to implement storing env values differently in the future,
so let's disconnect these methods from the instance variables
|
| | |
|
| |
| |
| |
| | |
we're already doing this with a bunch of other header data.
|
| |
| |
| |
| | |
we have a method that knows how to get rack.input, so lets use that.
|
| |
| |
| |
| |
| |
| | |
We need to abstract the internals of the request object away from this
instance variable so that the values for `@env` can be calculated in a
different way.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This refactoring moves the controller class name that was on the route
set to the request. The purpose of this refactoring is for changes we
need to move controller tests to integration tests, mainly being able to
access the controller on the request instead of having to go through
the router.
[Eileen M. Uchitelle & Aaron Patterson]
|
| | |
|
| |
| |
| |
| |
| | |
we want to go through methods to access `env` because in the future that
ivar may not be available, or may be calculated lazily
|
| |
| |
| |
| |
| | |
now the parameter filter doesn't need to know about the env hash in
these two methds.
|
| |
| |
| |
| | |
Now the Headers internals don't depend on the env hash.
|
| |
| |
| |
| |
| | |
This prevents external mutations from impacting the internals of the
request or the Header object.
|
| |
| |
| |
| |
| | |
this reduces the API footprint for the env hash so that we can be more
flexible when changing API in the future
|
| |
| |
| |
| | |
This allows us to avoid calling `env_name` twice.
|
| |
| |
| |
| | |
duping the request will dup it's underlying env hash.
|
| | |
|
| |
| |
| |
| |
| | |
Since we are always responding with an array and using `any?`, we don't
need to check if an array is empty
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| | |
Actions are processed through `dispatch`, so they should have the
request set on them before any user land code can be executed. Lets
stop setting _env on the controller, and give access to it through the
`env` method.
|
| |
| |
| |
| |
| | |
this is another place that we should stop directly accessing the env
hash and let the request object take care of that for us
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
again, we want to hide the contents of `env` from the implementation.
Allocate a request object to access the contents of env, but save
allocations due to string literal allocations when accessing the env
hash.
|
| |
| |
| |
| |
| | |
hide the env key in the request object so that other code doesn't need
to know.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Fix Encoding::UndefinedConversionError with multibyte UTF-8 filename containing "%" character
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| | |
This decouples the `call` method from knowing the SCRIPT_NAME key and
offloads decisions about how to access script_name
|
| | |
|
|\ \
| | |
| | | |
Document, refactor and create test case for ActionDispatch::Response
|
| | |
| | |
| | |
| | | |
ActionDispatch::Response#charset= method
|
| | |
| | |
| | |
| | |
| | | |
Now that we have encoding strategies, we can just walk the params hash
once to encode as HWIA, and remove nils.
|
| | |
| | |
| | |
| | | |
we'll refactor deep munge mostly out of existence shortly
|
| | |
| | |
| | |
| | |
| | | |
this just pushes the conditional in to the case / when so we can switch
to method dispatch later
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 the possibility to only filter parameters based on
their full path instead of relying on the immediate key.
config.filter_parameters += ['credit_card.code']
{ 'credit_card' => { 'code' => '[FILTERED]' },
'source' => { 'code' => '<%= puts 5 %>' } }
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
People should be free to mutate the header object, but not to set a new
header object. That header object may be specific to the webserver, and
we need to hide it's internals.
|
| |
| |
| |
| |
| | |
this way we don't have to mutate the instance (as much) when writing a
rack response
|
| |
| |
| |
| | |
[Robin Dupret & Shunsuke Aida]
|
| |
| |
| |
| |
| |
| |
| | |
These methods had defined in 2004 by dhh in initial commit and `ActionDispatch::Request`
class has been inherited from `Rack::Request` class in 2009 by josh.
In 2014 these methods and more of them defined in `Rack::Request` class
so we don't need them anymore in rails codebase.
|