Permalink
Browse files

More optimizations on respond_to after a profile and benching:

App with simple respond_to:
  def index
    respond_to do |format|
      format.html
      format.xml
      format.json
    end
  end

On JRuby (after complete hotspot warmup) -- 8% improvement:
  550 requests per second after this commit
  510 requests per second with old method_missing technique

On MRI (8% improvement):
  430 requests per second after this commit
  400 requests per second with old method_missing technique
  • Loading branch information...
wycats committed Dec 27, 2008
1 parent f4f8923 commit 4f043a48381c142e308824e3b7e15435a61bbb53
Showing with 2 additions and 6 deletions.
  1. +2 −6 actionpack/lib/action_controller/mime_responds.rb
@@ -147,13 +147,9 @@ def any(*args, &block)
def self.generate_method_for_mime(mime)
sym = mime.is_a?(Symbol) ? mime : mime.to_sym
const = sym.to_s.upcase
- class_eval <<-RUBY
+ class_eval <<-RUBY, __FILE__, __LINE__ + 1
def #{sym}(&block) # def html(&block)
- if Mime::SET.include?(Mime::#{const}) # if Mime::Set.include?(Mime::HTML)
- custom(Mime::#{const}, &block) # custom(Mime::HTML, &block)
- else # else
- super # super
- end # end
+ custom(Mime::#{const}, &block) # custom(Mime::HTML, &block)
end # end
RUBY
end

6 comments on commit 4f043a4

@dkubb

This comment has been minimized.

Show comment Hide comment
@dkubb

dkubb Dec 28, 2008

Contributor

Another thing you might want to benchmark is using something like:

def #{sym} custom(Mime::#{const}) { |format| yield(format) } end

In DM we benchmarked this as faster than using &block explicitly.

Contributor

dkubb replied Dec 28, 2008

Another thing you might want to benchmark is using something like:

def #{sym} custom(Mime::#{const}) { |format| yield(format) } end

In DM we benchmarked this as faster than using &block explicitly.

@hcatlin

This comment has been minimized.

Show comment Hide comment
@hcatlin

hcatlin Dec 28, 2008

There is a wycats in my railz.

Help pls.

There is a wycats in my railz.

Help pls.

@adkron

This comment has been minimized.

Show comment Hide comment
@adkron

adkron Dec 29, 2008

Contributor

dkubb has a great idea. Anytime that you use &block ruby makes a new Proc from the parameter, even when no block is given. This can slow you down.

Contributor

adkron replied Dec 29, 2008

dkubb has a great idea. Anytime that you use &block ruby makes a new Proc from the parameter, even when no block is given. This can slow you down.

@lifo

This comment has been minimized.

Show comment Hide comment
@lifo

lifo Dec 29, 2008

Member

Not always. http://gist.github.com/11326

Member

lifo replied Dec 29, 2008

Not always. http://gist.github.com/11326

@NZKoz

This comment has been minimized.

Show comment Hide comment
@NZKoz

NZKoz Dec 29, 2008

Member

We actually already do that optimisation with active record (for count, all, etc) and it did make a difference there, but as pratik mentions it’s not quite so simple.

There’s also some subtle differences between the two with some uses (have a look at the core list around september).

If the benchmarks show it faster here, let’s go for it. but it’s not ‘free performance’

Member

NZKoz replied Dec 29, 2008

We actually already do that optimisation with active record (for count, all, etc) and it did make a difference there, but as pratik mentions it’s not quite so simple.

There’s also some subtle differences between the two with some uses (have a look at the core list around september).

If the benchmarks show it faster here, let’s go for it. but it’s not ‘free performance’

@adkron

This comment has been minimized.

Show comment Hide comment
@adkron

adkron Dec 29, 2008

Contributor

Hmm, going to have to do a little research to figure out when it is better and when it is not.

Contributor

adkron replied Dec 29, 2008

Hmm, going to have to do a little research to figure out when it is better and when it is not.

Please sign in to comment.