4 ms·
Interestingly, you didn't learn the full lesson: When optimizing, always consider the cost of doing the optimization vs. it's impact. In a project where you a
by ilc 1y ago
Interestingly, you didn't learn the full lesson:
When optimizing, always consider the cost of doing the optimization vs. it's impact.
In a project where you are looking a 45/30/25 type split. The 45 may actually be well optimized, so the real gains may be in the 30 or 25.
The key is to understand the impact you CAN have, and what the business value of that impact is. :)
The other rule I've learned is: There is always a slowest path.
- Swizec 1y ago> The key is to understand the impact you CAN have, and what the business value of that impact is. :) Like I tell everyone in system design interviews: AWS will rent you a machine with 32TB of RAM. Are you still sure about all this extra complexity?
- naniwaduni 1y ago... to the tune of about 10 cents a second, yeah. If you can hire a dev team to optimize one of those out, you plausibly come out ahead (well, vs face value).
- what 1y agoHow do you come out ahead hiring an entire team to save $6/hour?
- naniwaduni 1y agoThat's $6/minute, $360/hour. Granted, if you're using it at a scale approaching FTE costs, you probably want at least some reserved capacity and you're likely not paying face value, but then the comparison was never going to be rigorous anyway.
- what 1y agoOh, I’m an idiot. Sorry, ignore me.
- AnthonyMouse 1y agoThat's not even the main problem with the comparison. Suppose it was actually $6/hour. Even that's >$50k/year, indefinitely. How long does it take your team once to make that resource consumption go away permanently? An hour? Even a month? You'd still be ahead.
- progmetaldev 1y agoWorking for a smaller digital agency, while using .NET Framework, and then moving to .NET Core (now just .NET) this savings was felt. Using a performance profiler and slightly complicating the code a bit (at least in terms of the documentation for the CMS we use), I was able to get the code in less than the minimum recommended requirements for the base CMS software, without having to alter the source of the CMS. I did this with the Umbraco CMS, but also started using it in 2013 when the documentation was lacking, so reading the source code was a requirement to getting as much as possible out of the software.
- Swizec 1y agoHopefully if you’re doing something that actually needs that much RAM you’re also making 6-figures per hour in revenue. I’ve heard that some companies spend hundreds of millions per year on cloud hosting and it’s still worth it. I can’t even imagine that level of scale. PS: The context in which I bring this up is a design exercise that would deal with maybe 5gb of data per month. People really over-complicate it :)
- godelski 1y agoI didn't get that impression from their response. I mean I could be wrong, but in context of "use a profiler" I don't think anything you said runs counter. I think it adds additional information, and it's worth stating explicitly, but given my read yours comes off as unnecessarily hostile. I think we're all on the same page, so let's make sure we're on the same side because we have the same common enemy: those who use Knuth's quote to justify the slowest piece of Lovecraftian spaghetti and duct tape imaginable
- ilc 1y agoIt is hostile because I've seen people mess up optimization too many times. Sometimes leaving the spaghetti alone IS correct. Sometimes it isn't. But most awful spaghetti happens because what it was asked to do was awful, IMHO.
- bluGill 1y agoNearly all the awful spaghetti code I've seen started out as good code, but as requirements changed in unexpected ways fitting the new features of version 5.0 while keeping all the previous version features working resulted in a mess that nobody knows how to clean up without the expensive big rewrite.
- godelski 1y agoThis has been my experience as well. A real "the road to hell is paved with good intentions" situation. No one was intentionally acting malicious nor trying to make bad code, but the ultimate truth is that software "rots". We write for static environments, but the environment isn't static. I'd expect even rather junior programmers to recognize that the more time you spend working on a project the more new and unexpected things you find. New features, better ways to implement things, whatever. And ultimately, we all look back at code we wrote a year ago and are going to say "what idiot wrote this garbage?" I mean, if you don't, it is probably a sign that you aren't improving. It's impossible to write perfect code, and even if it was, what would be "perfect" is a moving target. So either way, you should be writing better code today when compared to yesterday. > without the expensive big rewrite. While it isn't possible to completely put this off, I find there's a helpful tactic to reduce spaghetti-creep. "Maintenance is cheaper than repair." People say "don't fix what isn't broken" but I think that's wrong. You should "fix" things before they are broken. Because frankly, it is cheaper to replace your visibly degrading water pipe than it is to wait for it to burst. You not only have to pay for the new pipe, but all the damage it caused when it broke. Maintenance increases longevity and helps you monitor so you can replace things before they break. Doesn't matter if you're plumbing water pipes or plumbing spaghetti, the tactic is the same.