hi-
contrary to what i''ve read, i''ve been unable to show that
components
are, in fact, slower than any other rendering process:
### a simple controller
cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > cat app/
controllers/bar_controller.rb
class BarController < ApplicationController
def initialize
@foo = 42
@bar = ''forty-two''
end
def foo
render :text => @foo
end
def bar
render :text => @bar
end
def foobar
render :text => [@foo, @bar].inspect #=> [42, "forty-two"]
end
end
### benchmarking
cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > ab -n 25 -
c 4 http://localhost:3000/bar/foobar|grep ''Requests''
Requests per second: 7.05 [#/sec] (mean)
### another controller which uses the simple controller above via
component_for (see attached code)
cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > cat app/
controllers/foo_controller.rb
class FooController < ApplicationController
def foobar
# get a handle on, and parameterize, a bar controller
bar_controller = component_for(:controller => ''bar'')
do
@foo = 42
@bar = ''forty-two''
end
# call two actions on the bar controller, reusing the entire
model+view+controller
foo = bar_controller.content_for :action => ''foo''
bar = bar_controller.content_for :action => ''bar''
render :text => [foo, bar].inspect #=> [42, "forty-two"]
end
end
### benchmarking
cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > ab -n 25 -
c 4 http://localhost:3000/foo/foobar|grep ''Requests''
Requests per second: 6.79 [#/sec] (mean)
so this seems to indicate that the above two routes, with and without
components, are essentially the same. does anyone have code showing
that they are significantly slower? my reading of the rails source
doesn''t show any significant work being done when components are
used, many objects are dup''d when possible, so this makes sense to
me. nonetheless the net is awash with people claiming this is not true.
ps. above is using lighttpd, perhaps mongrel would have issues with
concurrency?
kind regards.
-a
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
Stefan kaes would be the guy to talk to about this. While performance is / was a concern, it was not a reason for our lack of enthusiasm for component based web development. So a solution to any performance issues is unlikely to improve the perception of render_component in many people''s eyes. On 5/21/07, ara.t.howard <ara.t.howard@gmail.com> wrote:> > > hi- > > contrary to what i''ve read, i''ve been unable to show that components > are, in fact, slower than any other rendering process: > > ### a simple controller > cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > cat app/ > controllers/bar_controller.rb > class BarController < ApplicationController > def initialize > @foo = 42 > @bar = ''forty-two'' > end > def foo > render :text => @foo > end > def bar > render :text => @bar > end > def foobar > render :text => [@foo, @bar].inspect #=> [42, "forty-two"] > end > end > > ### benchmarking > cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > ab -n 25 - > c 4 http://localhost:3000/bar/foobar|grep ''Requests'' > Requests per second: 7.05 [#/sec] (mean) > > > ### another controller which uses the simple controller above via > component_for (see attached code) > cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > cat app/ > controllers/foo_controller.rb > class FooController < ApplicationController > def foobar > # get a handle on, and parameterize, a bar controller > bar_controller = component_for(:controller => ''bar'') do > @foo = 42 > @bar = ''forty-two'' > end > > # call two actions on the bar controller, reusing the entire > model+view+controller > foo = bar_controller.content_for :action => ''foo'' > bar = bar_controller.content_for :action => ''bar'' > > render :text => [foo, bar].inspect #=> [42, "forty-two"] > end > end > > ### benchmarking > cfp:~/src/ruby/componentry/componentry-0.0.0/sample/rails > ab -n 25 - > c 4 http://localhost:3000/foo/foobar|grep ''Requests'' > Requests per second: 6.79 [#/sec] (mean) > > > so this seems to indicate that the above two routes, with and without > components, are essentially the same. does anyone have code showing > that they are significantly slower? my reading of the rails source > doesn''t show any significant work being done when components are > used, many objects are dup''d when possible, so this makes sense to > me. nonetheless the net is awash with people claiming this is not true. > > ps. above is using lighttpd, perhaps mongrel would have issues with > concurrency? > > kind regards. > > -a > -- > we can deny everything, except that we have the possibility of being > better. simply reflect on that. > h.h. the 14th dalai lama > > > > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On May 22, 2007, at 10:50 PM, Michael Koziarski wrote:> > Stefan kaes would be the guy to talk to about this. > > While performance is / was a concern, it was not a reason for our lack > of enthusiasm for component based web development. So a solution to > any performance issues is unlikely to improve the perception of > render_component in many people''s eyes.okay. good to know. i''m not sure where i''m headed - but the general idea may involve components: http://drawohara.tumblr.com/post/2070878 kind regards. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On May 22, 2007, at 10:50 PM, Michael Koziarski wrote:> > Stefan kaes would be the guy to talk to about this. > > While performance is / was a concern, it was not a reason for our lack > of enthusiasm for component based web development. So a solution to > any performance issues is unlikely to improve the perception of > render_component in many people''s eyes. >it''s not speed i''m after - it''s abstraction and the ability to perform database activity once in a clean and encapsulated way and then reuse data for two or more views. http://drawohara.tumblr.com/post/2338309 kind regards. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
There was a presentation at RejectConf about something similar: The ability to encapsulate partial logic in a controller method to get all the DRY goodness without the need for components. I think it was done by someone in the NY group, but I am not sure. Does anyone remember who did this? It might be just the thing you are looking for. -- Thank you, Steven A Bristol steve@lesseverything.com Home page: http://lesseverything.com Blog: http://b.lesseverything.com What you need: http://lessaccounting.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---