[bunderbunder]

Push less data through wires.

The memory hierarchy is so stark on modern hardware that the 30-year-old adage that "the fastest code is the code you don't run" is maybe less important than, "the fastest code is the code that doesn't spend much time talking to the memory controller."

And it's even worse once we start talking about accessing memory that's on an entirely different computer. Serialization/deserialization, IPC, network calls, and all those other things we do with reckless abandon in modern service-oriented and distributed applications are just unbelievably expensive.

Last year I took a slow heavily parallelized batch job and improved its throughput by 60% by getting rid of both scale-out and multithreading and just taking it all down to a single thread. Everyone expected it to be slower because we were using a small fraction as many CPU cores, but in truth it was faster because the time savings from having fewer memory fences, less data copying, and less network I/O was just that great. And then the performance gains kept coming because, having simplified things to that extent, I was then in a much better position to judiciously re-introduce parallelism in ways ways that weren't so wasteful.

[tracker1]

I've seen that happen a lot as JSON(XHR) and ORMs started to become more common... certain queries would return way too much data from related (auto-fetched) records and it was just slow AF on remote computers.

Another common one is just poor query performance from a database. Lack of appropriate indexes, or other relatively easy optimizations.

Similarly, finding a method of caching that's just bad (in-memory database, with sql queries instead of a dictionary). Isn't so bad for one call, very bad when a a given request (login) makes over 200 calls to this cache for configuration settings. It wasn't a problem per request but in aggregate.

[spicybbq]

> Push less data through wires.

In the systems I work on this has been a big one. In SQL people are pretty good about not writing `select *` in production code, but when querying directory servers, redis, mongodb, etc. people get sloppy. When a system is small, it's enticing to pull in lots of data and work with it in code instead of writing real queries. This doesn't scale.

[bunderbunder]

Unless you use an ORM, in which case I'm used to seeing it be all SELECT * all the time. And then you get an entire generation of engineers who've never known any other way to talk to a database going around complaining about how this Miata is so slow when really it's just that nobody ever taught them how to shift out of first gear.

[pdimitar]

Your example can really go either way. I've done tht exact opposite, with crushing success.