aboutsummaryrefslogtreecommitdiffstats
path: root/actionview/lib/action_view/lookup_context.rb
Commit message (Collapse)AuthorAgeFilesLines
* Freeze string literals when not mutated.schneems2015-07-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* [skip ci] Lookup can be a noun but it is not a verbJon Atack2015-07-171-4/+5
| | | | Various grammar corrections and wrap to 80 characters.
* [ci skip] Fix to Fixed-width Fontyui-knk2015-06-141-1/+1
| | | | LookupContext is class name
* head no_content when there is no template or action performedStephen Bussey2015-04-051-1/+1
|
* Template lookup now respect default locale and I18n fallbacks.Rafael Mendonça França2014-12-291-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use &= instead of select with include?Rafael Mendonça França2014-07-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* remove Set.new from DetailsKey::get, impacts rendering overhead performanceLuke Gruber2014-06-251-1/+1
| | | | | | | | | 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.
* Typo, grammar and textual changes [ci skip]Akshay Vishnoi2014-05-031-4/+5
|
* Fix the resolver cache and stop mutating the lookup_contextRafael Mendonça França2014-03-141-9/+8
| | | | | Before we had a bug in the resolver cache so the disable_cache were not working when passing options to find
* Introduce #with_formats_and_variants to prevent problems with mutating ↵Łukasz Strzałkowski2014-03-141-0/+8
| | | | finder object
* just require the template resolverAaron Patterson2014-01-311-0/+1
| | | | | | 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
* Action Pack VariantsŁukasz Strzałkowski2013-12-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Only use valid mime type symbols as cache keysAaron Patterson2013-12-021-0/+7
| | | | CVE-2013-6414
* Move actionpack/lib/action_view* into actionview/libPiotr Sarnacki2013-06-201-0/+241