3 ms·
> how could they not figure that out in their own testing This one is easy. Testing with little data on fast network (likely localhost).
by gray_-_wolf 3y ago
> how could they not figure that out in their own testing
This one is easy. Testing with little data on fast network (likely localhost).
- codetrotter 3y agoAlso, if there are any ORMs involved it could be that it’s not immediately obvious from their code itself that this would happen. I’ve seen code that was using an ORM, where they needed to find some data that matched certain criteria. With plain SQL it would have resulted in just a few rows of data. Put instead with their use of the ORM they ended up selecting all rows in the table from the database, and then looping over the resulting rows in code. The result of that was that the code was really slow to run, for something that would’ve been super fast if it wasn’t for the way they used the ORM in that code.
- mrighele 3y agoI just see recently an example of that, a REST call returning a few KB of data that would fetch a few million rows from the database and use 10+ GB of memory (unfortunately some people think that you should always use join fetches with JPA...).
- xp84 3y agoSeen this so many times by novice developers, whose work style is often "Trial and error, and as soon as it works, stop and change nothing." And it's so easy to slip in there because it works perfectly locally and often even in non-production envs, unless you've seeded them with production-like amounts of data, and with the ORM it looks fine. Like in Rails: Product.where(category_id: xx).filter {|p| p.name.include?("computer") } vs Product.where(category_id: xx).where("name like '%?%'", "computer") PS: I know there's an Arel way of doing the above without putting any SQL into the app -- use your imagination and pretend that's what I did, because I still don't have that memorized :)