I originally posted this on comp.lang.ruby, but in case someone has a different perspective here who doesn''t read that newsgroup, here it is: Brian --- When running a test that primarily involves loading up a few MySQL tables with ActiveRecord objects, I was surprised to see the Ruby CPU utilization at 93% and the MySQL CPU utilization at 7%. I would expect this workload to be heavier on MySQL than that. I would think inserts (particularly with updating several foreign key indices) would tax the database more than Ruby. Has this been other folks'' experience? Is running in the test environment incredibly different than production with respect to CPU utilization? I suppose my next step is to run in production to see what kind of results I get. I''m running the test from the root of my Rails project via: ruby test/unit/foo.rb Here''s part of the profiler output: % time name 7.96 ActiveRecord::ConnectionAdapters::Quoting.quote 5.61 ActiveRecord::Base#read_attribute 5.15 ActiveRecord::Base#column_for_attribute 4.25 ActiveRecord::Base#connection 3.74 Hash#[] 3.58 Array#each 3.30 ActiveRecord::ConnectionAdapters::MysqlAdapter#quote 3.16 ActiveRecord::ConnectionAdapters::Column#type_cast 2.84 Module#==2.65 ActiveRecord::Base#clone_attribute_value 2.29 ActiveRecord::Base#write_attribute 2.24 Kernel.class 2.22 Hash#each 2.08 String#to_s 2.03 ActiveRecord::Base#quote_value 1.59 Kernel.send 1.55 Array#include? 1.52 Kernel.=1.48 ActiveRecord::Base#unserializable_attribute? 1.39 Class#read_inheritable_attribute 1.34 Kernel.clone 1.29 ActiveRecord::Callbacks.notify 1.15 ActiveRecord::Base#method_missing 1.08 ActiveRecord::Base#columns_hash 1.08 ActiveRecord::Base#respond_to? 1.08 ActiveRecord::Callbacks.callback 0.99 Kernel.eval 0.95 Symbol#==0.90 Observable.notify_observers 0.88 ActiveRecord::ConnectionAdapters::Column#text? 0.85 Hash#[]0.85 Class#inheritable_attributes 0.83 Kernel.kind_of? 0.81 ActiveRecord::Base#convert_number_column_value ... [and from my followup post] I just moved my test code into a controller and ran it via: mongrel_rails start -e production Similar CPU characteristics except that Mongrel wasn''t able to fully utilize my dual core CPU (I suppose because of the serialization of Rails code due to lack of thread safetyness). So the unit test (1093 records -> table1, 1093 records -> table2, 1 record -> table3) took 5.5 seconds to complete and the identical test in a controller with Mongrel in production mode took 27.4 seconds! Yeah, I know I can have a cluster of Mongrel processes, and that''s how I run for real, but I''m still a little bummed with these results :( I''ve switched my company''s development from 100% Java to 100% Ruby, and I still believe that was a good decision because of productivity gains and joy, but I do miss some of the runtime performance of Java and the ease with which I could spin up a thread to do some background process. I''m glad BackgrounDRB has been provided, but it''s not quite the same. Hopefully future versions of Ruby/Rails will provide some more runtime performance and concurrency - I''d be glad if I could just fork in Rails without trouble, but I don''t think that''s the case. For now, I don''t have more customers than a Core 2 Duo can handle, so it''s not exactly on the critical path for me yet :) In fact, I''m glad MySQL isn''t on the critical path because overcoming that seems much more difficult than having a bunch of Apache/Mongrel processes running. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/7/07, Brian Adkins <lojicdotcomNOSPAM-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> zdennis wrote: > > On Mar 6, 10:30 pm, Brian Adkins <lojicdotcomNOS...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> When running a test that primarily involves loading up a few MySQL > >> tables with ActiveRecord objects, I was surprised to see the Ruby CPU > >> utilization at 93% and the MySQL CPU utilization at 7%. I would expect > >> this workload to be heavier on MySQL than that. > > > > What is your script doing? Can you post it? > > I created a smaller test that I could post that exhibits the same > characteristics: > > class PerfTestController < ApplicationController > def index > t1 = Time.now > 3000.times do > member = Member.new > member.first_name = ''Fred'' > member.last_name = ''Flintstone'' > member.address1 = ''123 High St.'' > member.city = ''Reykjavik'' > member.state = ''Michigan'' > member.email = ''fred-Dsuv1UYZSSTz1n+OaKNE4w@public.gmane.org'' > member.save! > end > t2 = Time.now > puts "Time elapsed = #{t2-t1}" > end > end > > That took 35.7 seconds (84 inserts per second) on a dual core 2 GHz AMD > Opteron. It pegged Mongrel and MySQL didn''t break a sweat. > > I just ran another test with a short ruby program inserting records > directly using the mysql gem and it only took 1.6 seconds (1,875 inserts > per second!), and the CPU utilization was as it should be - the MySQL > CPU was ten times as much as Ruby. So it definitely appears that > Rails/ActiveRecord is about 22 times as slow than a straight Ruby > program - wow! > > This result makes me feel much better since the performance of Ruby > seems fine. The fact that Rails/ActiveRecord is way slow isn''t hurting > me yet, and there is hope it can be sped up since it doesn''t appear to > be an inherent problem with Ruby. > > Here''s the schema for Member: > > create table members ( > id int not null auto_increment, > created_at datetime not null, > updated_at datetime not null, > first_name varchar(30) null, > last_name varchar(30) null, > address1 varchar(50) null, > address2 varchar(50) null, > city varchar(30) null, > state varchar(5) null, > email varchar(100) null, > home_phone varchar(25) null, > primary key(id) > ) engine=InnoDB;Hi Brian, I wrapped this up in a simple script that anyone with MySQL or SQLite and the AR gem can run. It benchmarks AR create vs using the db connection directly. See attached. Excerpted results on a new MacBook Pro: user system total real raw quoted 0.460000 0.000000 0.460000 ( 0.480184) create 2.760000 0.080000 2.840000 ( 3.225227) (Nearly 7 times slower.) I haven''t tried profiling the methods yet. In my experience with typical Rails apps, you''ll hit a wall with ERB template rendering much sooner than with Active Record creation. This is an interesting pursuit nonetheless -- I''m interested to see what you all come up with. Best regards, jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/7/07, Jeremy Kemper <jeremy@bitsweat.net> wrote:> I wrapped this up in a simple script that anyone with MySQL or SQLite > and the AR gem can run. It benchmarks AR create vs using the db > connection directly. See attached. > > Excerpted results on a new MacBook Pro: > user system total real > raw quoted 0.460000 0.000000 0.460000 ( 0.480184) > create 2.760000 0.080000 2.840000 ( 3.225227) > > (Nearly 7 times slower.) I haven''t tried profiling the methods yet.An updated script that actually works with MySQL is attached ;-) Transactions make a huge difference with MySQL compared to the negligible impact with in-memory SQLite. user system total real raw quoted 0.480000 0.120000 0.600000 ( 2.530020) raw quoted txn 0.230000 0.060000 0.290000 ( 0.546332) create 3.170000 0.320000 3.490000 ( 5.685493) create txn 1.990000 0.090000 2.080000 ( 2.392676) (2.2x slower without a transaction; 4.4x slower with) jeremy
Jeremy Kemper wrote:> On 3/7/07, Brian Adkins <lojicdotcomNOSPAM-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> zdennis wrote: >> >>> On Mar 6, 10:30 pm, Brian Adkins <lojicdotcomNOS...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> >>>> When running a test that primarily involves loading up a few MySQL >>>> tables with ActiveRecord objects, I was surprised to see the Ruby CPU >>>> utilization at 93% and the MySQL CPU utilization at 7%. I would expect >>>> this workload to be heavier on MySQL than that. >>>> >>> What is your script doing? Can you post it? >>> >> I created a smaller test that I could post that exhibits the same >> characteristics: >> >> class PerfTestController < ApplicationController >> def index >> t1 = Time.now >> 3000.times do >> member = Member.new >> member.first_name = ''Fred'' >> member.last_name = ''Flintstone'' >> member.address1 = ''123 High St.'' >> member.city = ''Reykjavik'' >> member.state = ''Michigan'' >> member.email = ''fred-Dsuv1UYZSSTz1n+OaKNE4w@public.gmane.org'' >> member.save! >> end >> t2 = Time.now >> puts "Time elapsed = #{t2-t1}" >> end >> end >> >> That took 35.7 seconds (84 inserts per second) on a dual core 2 GHz AMD >> Opteron. It pegged Mongrel and MySQL didn''t break a sweat. >> >> I just ran another test with a short ruby program inserting records >> directly using the mysql gem and it only took 1.6 seconds (1,875 inserts >> per second!), and the CPU utilization was as it should be - the MySQL >> CPU was ten times as much as Ruby. So it definitely appears that >> Rails/ActiveRecord is about 22 times as slow than a straight Ruby >> program - wow! >> >> This result makes me feel much better since the performance of Ruby >> seems fine. The fact that Rails/ActiveRecord is way slow isn''t hurting >> me yet, and there is hope it can be sped up since it doesn''t appear to >> be an inherent problem with Ruby. >> >> Here''s the schema for Member: >> >> create table members ( >> id int not null auto_increment, >> created_at datetime not null, >> updated_at datetime not null, >> first_name varchar(30) null, >> last_name varchar(30) null, >> address1 varchar(50) null, >> address2 varchar(50) null, >> city varchar(30) null, >> state varchar(5) null, >> email varchar(100) null, >> home_phone varchar(25) null, >> primary key(id) >> ) engine=InnoDB; >> > > > Hi Brian, > > I wrapped this up in a simple script that anyone with MySQL or SQLite > and the AR gem can run. It benchmarks AR create vs using the db > connection directly. See attached. > > Excerpted results on a new MacBook Pro: > user system total real > raw quoted 0.460000 0.000000 0.460000 ( 0.480184) > create 2.760000 0.080000 2.840000 ( 3.225227) > > (Nearly 7 times slower.) I haven''t tried profiling the methods yet. > > In my experience with typical Rails apps, you''ll hit a wall with ERB > template rendering much sooner than with Active Record creation. This > is an interesting pursuit nonetheless -- I''m interested to see what > you all come up with. > > Best regards, > jeremy > >Hi, are these results in production or development? Talking about template rendering, I''m just wondering if anyone has thought of pre-processing the template for a production environment. For example, I''d imagine it''s might convenient to do things like ''<% tylesheet_tag %>'' etc when linking in files. But, each time Rails hits one of those, it needs to render it. Would it make sense to have a smart pre-processor that goes through the templates to see what constants there are (like links to the same stylesheet, javascript files, etc.) and even things like "form_start_tag"/ "form_end_tag" etc. to pre-render it so that the number of times you need to create something is reduced. Has anyone benchmarked the time for rendering a page with many or few such items? It would be really interesting to have a tool that could pre-render such things for production.. Cheers Mohit. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/8/07, Mohit Sindhwani <mo_mail@onghu.com> wrote:> Jeremy Kemper wrote: > > Excerpted results on a new MacBook Pro: > > user system total real > > raw quoted 0.460000 0.000000 0.460000 ( 0.480184) > > create 2.760000 0.080000 2.840000 ( 3.225227) > > > Hi, are these results in production or development?There is no difference between the two in this case, so the script doesn''t set RAILS_ENV at all.> Talking about template rendering, I''m just wondering if anyone has > thought of pre-processing the template for a production environment. > For example, I''d imagine it''s might convenient to do things like ''<% > tylesheet_tag %>'' etc when linking in files. But, each time Rails hits > one of those, it needs to render it. Would it make sense to have a > smart pre-processor that goes through the templates to see what > constants there are (like links to the same stylesheet, javascript > files, etc.) and even things like "form_start_tag"/ "form_end_tag" etc. > to pre-render it so that the number of times you need to create > something is reduced.Yes! See Stefan Kaes'' template optimizer: http://railsexpress.de/plugins/trac> Has anyone benchmarked the time for rendering a page with many or few > such items?Yes. See Stefan''s blog; he regularly benchmarks his apps against each new Rails release. I think he''s covered the impact of the template optimizer. jeremy
Jeremy Kemper wrote:> On 3/8/07, Mohit Sindhwani <mo_mail-RxrYI66vbj0AvxtiuMwx3w@public.gmane.org> wrote: > >> Jeremy Kemper wrote: >> >>> Excerpted results on a new MacBook Pro: >>> user system total real >>> raw quoted 0.460000 0.000000 0.460000 ( 0.480184) >>> create 2.760000 0.080000 2.840000 ( 3.225227) >>> >>> >> Hi, are these results in production or development? >> > > There is no difference between the two in this case, so the script > doesn''t set RAILS_ENV at all. > > > >> Talking about template rendering, I''m just wondering if anyone has >> thought of pre-processing the template for a production environment. >> For example, I''d imagine it''s might convenient to do things like ''<% >> tylesheet_tag %>'' etc when linking in files. But, each time Rails hits >> one of those, it needs to render it. Would it make sense to have a >> smart pre-processor that goes through the templates to see what >> constants there are (like links to the same stylesheet, javascript >> files, etc.) and even things like "form_start_tag"/ "form_end_tag" etc. >> to pre-render it so that the number of times you need to create >> something is reduced. >> > > Yes! See Stefan Kaes'' template optimizer: http://railsexpress.de/plugins/trac > > > >> Has anyone benchmarked the time for rendering a page with many or few >> such items? >> > > Yes. See Stefan''s blog; he regularly benchmarks his apps against each > new Rails release. I think he''s covered the impact of the template > optimizer. > > jeremyThanks! COOL! That''s what I need to take a look at.. you learn 7 new things on this list every day :) Cheers Mohit. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hello Jeremy. Are you saying that config/production.rb and config/development.rb are identical? -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) On Mar 8, 2007, at 4:55 AM, Jeremy Kemper wrote:> > On 3/8/07, Mohit Sindhwani <mo_mail-RxrYI66vbj0AvxtiuMwx3w@public.gmane.org> wrote: >> Jeremy Kemper wrote: >>> Excerpted results on a new MacBook Pro: >>> user system total real >>> raw quoted 0.460000 0.000000 0.460000 ( 0.480184) >>> create 2.760000 0.080000 2.840000 ( 3.225227) >>> >> Hi, are these results in production or development? > > There is no difference between the two in this case, so the script > doesn''t set RAILS_ENV at all.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/8/07, Jeremy Kemper <jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> wrote:> On 3/7/07, Brian Adkins <lojicdotcomNOSPAM-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > zdennis wrote: > > > On Mar 6, 10:30 pm, Brian Adkins <lojicdotcomNOS...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > >> When running a test that primarily involves loading up a few MySQL > > >> tables with ActiveRecord objects, I was surprised to see the Ruby CPU > > >> utilization at 93% and the MySQL CPU utilization at 7%. I would expect > > >> this workload to be heavier on MySQL than that. > > > > > > What is your script doing? Can you post it? > > > > I created a smaller test that I could post that exhibits the same > > characteristics: > > > > class PerfTestController < ApplicationController > > def index > > t1 = Time.now > > 3000.times do > > member = Member.new > > member.first_name = ''Fred'' > > member.last_name = ''Flintstone'' > > member.address1 = ''123 High St.'' > > member.city = ''Reykjavik'' > > member.state = ''Michigan'' > > member.email = ''fred-Dsuv1UYZSSTz1n+OaKNE4w@public.gmane.org'' > > member.save! > > end > > t2 = Time.now > > puts "Time elapsed = #{t2-t1}" > > end > > end > > > > That took 35.7 seconds (84 inserts per second) on a dual core 2 GHz AMD > > Opteron. It pegged Mongrel and MySQL didn''t break a sweat. > > > > I just ran another test with a short ruby program inserting records > > directly using the mysql gem and it only took 1.6 seconds (1,875 inserts > > per second!), and the CPU utilization was as it should be - the MySQL > > CPU was ten times as much as Ruby. So it definitely appears that > > Rails/ActiveRecord is about 22 times as slow than a straight Ruby > > program - wow! > > > > This result makes me feel much better since the performance of Ruby > > seems fine. The fact that Rails/ActiveRecord is way slow isn''t hurting > > me yet, and there is hope it can be sped up since it doesn''t appear to > > be an inherent problem with Ruby. > > > > Here''s the schema for Member: > > > > create table members ( > > id int not null auto_increment, > > created_at datetime not null, > > updated_at datetime not null, > > first_name varchar(30) null, > > last_name varchar(30) null, > > address1 varchar(50) null, > > address2 varchar(50) null, > > city varchar(30) null, > > state varchar(5) null, > > email varchar(100) null, > > home_phone varchar(25) null, > > primary key(id) > > ) engine=InnoDB; > > > Hi Brian, > > I wrapped this up in a simple script that anyone with MySQL or SQLite > and the AR gem can run. It benchmarks AR create vs using the db > connection directly. See attached. > > Excerpted results on a new MacBook Pro: > user system total real > raw quoted 0.460000 0.000000 0.460000 ( 0.480184) > create 2.760000 0.080000 2.840000 ( 3.225227) > > (Nearly 7 times slower.) I haven''t tried profiling the methods yet. > > In my experience with typical Rails apps, you''ll hit a wall with ERB > template rendering much sooner than with Active Record creation. This > is an interesting pursuit nonetheless -- I''m interested to see what > you all come up with. > > Best regards, > jeremyJeremy Are there, or could there be, performance tests like this added to the Rails test suite? It would be great to be able to track performance like this over Rails releases. - Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/8/07, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote:> Are you saying that config/production.rb and config/development.rb > are identical?No, sorry: it doesn''t load a Rails environment at all, just vanilla Active Record. The Rails environment has no bearing on Active Record in isolation, beyond choosing the default database connection: $ grep -r RAILS_ENV lib/ |grep -v svn|wc -l 2 Your Rails app reloads application classes during development so some AR caches, like the per-class table metadata, are wiped as a result. jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/8/07, Rob Sanheim <rsanheim@gmail.com> wrote:> Are there, or could there be, performance tests like this added to the > Rails test suite? It would be great to be able to track performance > like this over Rails releases.Sure; I think so. But I don''t want to compile or maintain the suite ;-) jeremy
M. Edward (Ed) Borasky
2007-Mar-09 04:48 UTC
Re: [Rails] Re: High ActiveRecord CPU Utilization
Jeremy Kemper wrote:> On 3/8/07, Rob Sanheim <rsanheim@gmail.com> wrote: >> Are there, or could there be, performance tests like this added to the >> Rails test suite? It would be great to be able to track performance >> like this over Rails releases. > > Sure; I think so. But I don''t want to compile or maintain the suite ;-) > > jeremy > >I would think someone in the "core Rails team" would step up to the plate for Rails-specific benchmarks. But if the specific case under discussion here -- ActiveRecord -- turns out to have a bottleneck somewhere in the Ruby interpreter, rather than just an inefficient strategy in the ActiveRecord code itself, then I''d say this benchmark belongs in a Ruby benchmark suite rather than a Rails benchmark suite. -- M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P) http://borasky-research.blogspot.com/ If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
On Friday 09 March 2007, M. Edward (Ed) Borasky wrote:> Jeremy Kemper wrote: > > On 3/8/07, Rob Sanheim <rsanheim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Are there, or could there be, performance tests like this added to > >> the Rails test suite? It would be great to be able to track > >> performance like this over Rails releases. > > > > Sure; I think so. But I don''t want to compile or maintain the suite > > ;-) > > > > jeremy > > I would think someone in the "core Rails team" would step up to the > plate for Rails-specific benchmarks. But if the specific case under > discussion here -- ActiveRecord -- turns out to have a bottleneck > somewhere in the Ruby interpreter, rather than just an inefficient > strategy in the ActiveRecord code itself, then I''d say this benchmark > belongs in a Ruby benchmark suite rather than a Rails benchmark > suite.I don''t know about writing records to the DB, but for reading the AR code is just inefficient as it involves just too many hash accesses. In pre-1.0 times, I''ve written a patch that replaced hash operations as much as possible with array operations[1]. The performance improvement was noticeable, see the ticket for details. But all that was ages ago and I haven''t updated the patch for the considerable changes that came with Rails 1.0. Michael [1] http://dev.rubyonrails.org/ticket/2172 -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 3/9/07, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> I don''t know about writing records to the DB, but for reading the AR > code is just inefficient as it involves just too many hash accesses. In > pre-1.0 times, I''ve written a patch that replaced hash operations as > much as possible with array operations[1]. The performance improvement > was noticeable, see the ticket for details. But all that was ages ago > and I haven''t updated the patch for the considerable changes that came > with Rails 1.0. > > Michael > > [1] http://dev.rubyonrails.org/ticket/2172I''ve had this patch starred in my gmail ticket-box for so long, Michael. Sorry I haven''t PDIed it up to edge yet :-( jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---