Home
Starting Up
Case Studies DB
Products
Ideas DB
Vibe Coding Tools
Subscribe to IH+
Starting Up
Case Studies
Ideas DB
Products DB
Join
16
Likes
9
Comments
Making code faster
by
Ryan Randall
https://www.tbray.org/ongoing/When/202x/2022/06/10/Quamina-Optimizing
It is also really important to choose your benchmarks carefully, and understand the limitations of the benchmark situation. At my last company, we started by building some micro-benchmarks to see what design decisions mattered, but as the code base grew, many of the early design choices we made for performance, actually slowed things down because it increased total code size. If we had waited and optimized later, we would have made better decisions and avoided some painful changes.
Yeah same goes for abstracting; wait until you have a few examples in where it can be use to abstract this or that out.
i agree somewhat, i think its good to write code, make sure it works, then optimize, but i think it is completly situational.
I keep this in mind often. You need to make the product work before you can optimize it. My mentor tells me "build incrementally" and to take it line by line. There's nothing wrong with making sure your code is working as expected every few lines. If you're writing multiple lines without testing then your chance of running into multiple errors increases.
Refactoring is worth doing, but would I prioritize it over trying to the product in the hands of clients? Probably not. Refactoring is a necessary evil once you've got users, but until you've got your first users, perfect is the enemy of good.
Coming from Computer Engineering (System BIOS, OS/Device Drivers), I use to optimize everything. One of my boss said the CPU is going so fast that optimization doesn't matter (on a product that performance really matters). I left his team. That said, it really depends on what you are building. Sometimes, choosing right platform at the start can help. I uses Blazor WASM now. A typical performance comparison vs Javascript is that WASM is 50x faster.
"Premature optimization is the root of all evil" - I've read this so many times and I really don't agree. Not only because most absolute statements like this tend to completely ignore any form of circumstantial nuance, but because it implies there's a right way and a wrong way - which, for such a broadly applicable statement, I don't think can be the case.
I definitely agree there's nuance to it. But I think overall, it is generally a good framework to follow. If anything, a useful catchphrase to check yourself and make sure you aren't going overboard optimizing.
Too often when leading engineering teams, I've noticed that engineers can almost become borderline obsessed with over optimizing something in an agile environment - expending too many valuable resources trying to make something fast, when we're still in the phase where we need to actually test the code out. We might even throw that code out later on.
Now with that said, doing a little pre-optimization during the architecture phase: particularly with how data is going to flow throughout the application and how it will be stored (and how to be efficient with these things) is absolutely something you should spend time on. Because it will significantly impact everything else that happens from backend to frontend.
I understood what they're saying to mean that upfront performance considerations in the design are not necessarily a case of premature optimization. Plus, in this context, if you know something ought to be performing fast and it isn't, it's arguably not premature to work to make it faster (you know it's not performing as well as it should be).