3 ms·

Still calling bullshit. You have to purposefully intend to get performance that bad in order to make ActiveRecord do the wrong thing that blatantly. The actual

Still calling bullshit. You have to purposefully intend to get performance that bad in order to make ActiveRecord do the wrong thing that blatantly. The actual query execution is extremely lazy, that is, it doesn't execute the query until all the final chained method has been added to the planner.

brightball 11y ago
Oh man, I wish I still had that code. These guys were militant "all logic in the objects" types so when they had to create a dashboard page, instead of just doing a scope with a couple of joins and the proper criteria; they went off of the base object, got the first set of associations, checked to see if it met the criteria by looping through the results and calling the object methods (which made associated calls to evaluate their comparisons under the hood) before finally converting the entire result set of about 20,000 objects into an array so that it could be sorted and the trimmed to exact number of records that were supposed to be displayed on that particular page. It was brutal. You would have thought it would require real, serious, effort to pull off that level of scary. I don't have the code to offer, but I can cite a couple of blog posts that I wrote about it a while back. It was so bad that I not only start blogging more because of it but I also taught a class to try to teach people both Rails AND PostgreSQL so they couldn't get into a situation of learning one without the other. Here's the posts... The Drawback to Web Frameworks (2013) - http://www.brightball.com/ruby/the-drawback-to-web-frameworks http://www.brightball.com/ruby/the-drawback-to-web-framework... "In order to look up what the status was on a particular object related to a user, they used some beautiful looking Rails code to find, filter, and combine results (and THEN paginate). The problem is that after Rails goes one level deep from a single record it starts performing single queries for each record in each relationship. That meant, for example, that in order to retrieve the most recent objects for a user who had over 18,000 in his account history that upwards of 50,000 queries were executed. The results of those 50,000 queries were then loaded into the web server's RAM (and SWAP), processed/sorted/filtered, and THEN paginated just to show the first 100 results. It was appalling and that is only one example." And here's the class that I taught to try to stop it from happening ever again. :-) http://www.brightball.com/classes/ruby-on-rails-and-postgresql-intro-to-advanced-in-3-weeks http://www.brightball.com/classes/ruby-on-rails-and-postgres...

brightball 11y ago

Oh man, I wish I still had that code. These guys were militant "all logic in the objects" types so when they had to create a dashboard page, instead of just doing a scope with a couple of joins and the proper criteria; they went off of the base object, got the first set of associations, checked to see if it met the criteria by looping through the results and calling the object methods (which made associated calls to evaluate their comparisons under the hood) before finally converting the entire result set of about 20,000 objects into an array so that it could be sorted and the trimmed to exact number of records that were supposed to be displayed on that particular page. It was brutal. You would have thought it would require real, serious, effort to pull off that level of scary. I don't have the code to offer, but I can cite a couple of blog posts that I wrote about it a while back. It was so bad that I not only start blogging more because of it but I also taught a class to try to teach people both Rails AND PostgreSQL so they couldn't get into a situation of learning one without the other. Here's the posts... The Drawback to Web Frameworks (2013) - http://www.brightball.com/ruby/the-drawback-to-web-frameworks http://www.brightball.com/ruby/the-drawback-to-web-framework... "In order to look up what the status was on a particular object related to a user, they used some beautiful looking Rails code to find, filter, and combine results (and THEN paginate). The problem is that after Rails goes one level deep from a single record it starts performing single queries for each record in each relationship. That meant, for example, that in order to retrieve the most recent objects for a user who had over 18,000 in his account history that upwards of 50,000 queries were executed. The results of those 50,000 queries were then loaded into the web server's RAM (and SWAP), processed/sorted/filtered, and THEN paginated just to show the first 100 results. It was appalling and that is only one example." And here's the class that I taught to try to stop it from happening ever again. :-) http://www.brightball.com/classes/ruby-on-rails-and-postgresql-intro-to-advanced-in-3-weeks http://www.brightball.com/classes/ruby-on-rails-and-postgres...