3 ms·
I've worked in a couple of projects where the existing teams were converting some API calls to new tech and changing UI to accomodate the 'new way' of getting d
by lowercased 3y ago
I've worked in a couple of projects where the existing teams were converting some API calls to new tech and changing UI to accomodate the 'new way' of getting data because "the current is way too slow". And it was. Going to a common dashboard was taking... 45-50 seconds, and growing.
Core was they were pulling all data - 20k records - in to a js datatable.
"This is bad - we have to move to server side paging!"
They'd convinced their clients (I've seen this variations of this process 5x in the past 6 years) to 'upgrade'.
In at least 2 cases, I rewrote a couple of the queries to just pull what was needed - id/name/email - instead of full ORM records with nested associations. One screen went from 45 seconds to 1 second. And this took ... 10-15 minutes of digging and rework. Yes, if your real goal is you want to learn Hotwire or some other new tech... go for it, but it feels wrong to not even investigate why the code is slow in the first place.
Other project - similar - took a screen from 50 seconds to 2 seconds by reducing the query. Then got the whole thing under a second with a couple of indexes.
Now, yes, this isn't all specific to database optimization, but they feel related. This idea of "oh, compute is cheap, devs are expensive, just throw more hardware at it!" has to have some boundaries/limits, but they aren't often realized until you're really ... in deep.
- krembo 3y agoAs a dba that gives professional services to solve postgres performance issues, I've seen the same too fu*ing many times that it made my eyes bleed.