3 ms·
> You may make your function 2x faster, at a cost of additional complexity, but you never run it enough in a year for it to pay itself back. "You" is both sing
by jjav 2y ago
> You may make your function 2x faster, at a cost of additional complexity, but you never run it enough in a year for it to pay itself back.
"You" is both singular and plural, which is often the problem with this thinking.
Is it worth spending a month of engineering time to make a page load in 50ms instead of 2s? Seems like a lot of engineering time for a noticeable but somewhat minor improvement.
But now, what if you have a million users who do this operation 100x/day? Absolutely worth it!
For example, I sure wish atlassian would spend a tiny bit of effort into making jira faster. Even if it is 1 second per ticket, since I'm viewing 100+ tickets per day that adds up. And there's many hundreds of us at the company doing the same thing, it really adds up.
- ddtaylor 2y ago> 50ms instead of 2s In the past I believe Google was very adament that page load time perception was very important to other metrics.
- sfn42 2y agoYou're probably not going to achieve that with the kind of optimization described in this article though.
- nottorp 2y agoMost of the time they just move the expensive processing to the user's browser so they don't have to pay for it :)
- xlii 2y agoNit: 50ms vs 2000ms is 40x speed increase, i.e. ~1.5 order of magnitude. I still keep words of my database optimization lecturer who said that by his experience optimization below 1 OOM aren’t worth it and most „good ones” are 3+ > Absolutely worth it! Long reaching assumption. Even the biggest companies have limited resources (even if vast). Would you rather improve load times by 2x (from 500ms to 250ms) or improve checkout reliability from 99% to 99.5%? And there is much more to consider on some levels (e.g. planning for thermal efficiency is fun). Software development is always a game of choice.
- sgarland 2y ago> I still keep words of my database optimization lecturer who said that by his experience optimization below 1 OOM aren’t worth it and most „good ones” are 3+ Like everything, it depends. Is the query gating a lot of other things, especially things that can be done in parallel? Shaving 10 ms off might very well be meaningful. Is it a large OLAP query, and the owning team has SLAs that depend on it? Going from 60 --> 55 minutes might actually matter. The two biggest performance-related issues with RDBMS that I deal with, aside from indexing choices, are over-selection (why on earth do ORMs default to SELECT * ?), and poor JOIN strategies. Admittedly the latter is often a result of poor schema design, but for example, the existence of semi/anti-joins seems to be uncommon knowledge.
- xlii 2y agoIf SLAs are involved then I’d argue it’s not about optimization but about business goals, which unsurprisingly take precedence. But there is another case that is very similar: threshold passing (or how I like to call it - waterfalling). Small inefficiencies add up and at some point a small slowdowns reach critical mass and some significant system breaks everything else. When system was designed by competent engineers huge optimizations aren’t easy, so it’s shaving couple millis here and couple millis there. But, as in the first case, I’d categorize it as a performance failure.
- Cthulhu_ 2y agoAs always, https://xkcd.com/1205/ https://xkcd.com/1205/ is a great reference to keep in mind. That said, most developers (I assume, by most I mean myself) never work with code where the work they do has any serious impact on performance; it's layers on top of code that should be fast, but the work I do is implementing business logic and screens, in which case readability vastly trumps performance. I mean right now I'm writing a line of code that can be represented as a nested ternary or a function call with some more written-out if/elses. The ternary outperforms the function call 2:1 or more, but either one can be executed hundreds of times a second BUT will only be executed once or twice per page view. It's not worth the tradeoff, even if this line of code will be executed hundreds of millions of times overall.
- binary132 2y agoJira is incredibly slow, almost unusable. So awful.
- pphysch 2y agoMore features = more customers = more revenue More data collection = more revenue More crap layered on = everything is slower Everything sucks = more support demand = supply price leverage = more revenue Enterprise software is necessarily slow and complicated, and not for your benefit.
- binary132 2y agoI’m not quite following your point. It sounds like you’re agreeing that Jira sucks?