TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Performance excuses debunked

141 pointsby brhsagainabout 2 years ago

29 comments

tomas789about 2 years ago
One more datapoint here. Good performance helps avoiding scaling problems. One example is an API I recently wrote. I was initially in Python and performance was OK I guess. I had to take care of horizontal scaling, how to manage the infrastructure, a bit of distributed scaling and all the other goodies that come along. By rewriting it in Rust and caring about performance I was able to run it on a single machine (which is ok for that product). That saved me quite some hustle. And my average response time went from 300ms to 29ms.<p>If the app would scale a lot I would still need to go into all that trouble but at this early stage the benefits of really simple infrastructure is immense.
评论 #35735223 未加载
JanneVeeabout 2 years ago
Well then further excuses come flying on why he is wrong again, and how performance doesn&#x27;t matter to them. I have a legacy code base that I until recently worked with that domain specific Business Intelligence product built with SOLID principles. 20% of the processes CPU usage was for the GC, whenever you made a dump of the process it was 99% fragmentation of memory and pointer chasing through object trees every time. The customers complain about performance because they aren&#x27;t getting their data in a timely manner and not getting the savings they were promised with the product. It is not a game but it does math on a bunch of data and there is a requirement to do it in a timely manner, which it is failing. Stop coming with excuses that it is niche, if you are doing anything useful to the data then you might want to pick up on Caseys advice.
评论 #35725231 未加载
charlie0about 2 years ago
Starts off with premise of why performance matters and why you should care. Proceeds to only top 10 biggest tech companies as examples. Are you working in a FAANG? If not, this article does nothing to convince me that I should care about performance (even though I kinda do).
评论 #35723642 未加载
评论 #35729115 未加载
评论 #35728971 未加载
评论 #35724538 未加载
评论 #35729364 未加载
评论 #35723633 未加载
umanwizardabout 2 years ago
Absolutely hilarious and ridiculous to claim that Facebook cares about iOS app performance. In reality they have a few dozen people who care making heroic technical fixes to mitigate the damage of thousands of people adding mountains of mediocre crap to the apps.<p>If you care about performance from the beginning, you would never even get to the point where you’re saying “oh crap, our messenger app can barely run, let’s rewrite it in C”.
评论 #35724505 未加载
评论 #35761719 未加载
评论 #35724248 未加载
magicalhippoabout 2 years ago
There&#x27;s often a lot of low hanging performance fruits when writing code.<p>Need to loop over some order lines and find distinct article numbers? Use a hash-based set with O(1) access, not just a list which will have O(n). If not you&#x27;ll end up writing an O(n^2) routine for no good reason, which will work swimmingly on you 10 line test order and cause grief in production.<p>I don&#x27;t think a lot about performance most of the time, just enough to try to avoid silly stuff.
评论 #35726854 未加载
评论 #35723539 未加载
alphanumeric0about 2 years ago
&quot;With so much evidence refuting the five excuses, hopefully it is clear that they are ridiculous. They are completely invalid reasons for the average developer, in the common case, to dismiss concerns about software performance. They should not be taken seriously in a professional software development context.&quot;<p>I believe the average developer should care somewhat about performance, and depending on their industry they might need to care <i>a lot</i>, but I&#x27;m not so convinced for the average case.<p>The average developer is not working on FAANG-sized codebases. Also, I&#x27;d imagine <i>any</i> large systems built up over the years that are refactored would likely see great performance gains. That&#x27;s just the nature of long-term software.
li4ickabout 2 years ago
You know, reading these comments is absolutely hilarious. It&#x27;s because of this and that, hundreds of excuses that dance around the simple truth: you&#x27;re an incompetent programmer. That&#x27;s it. No, you&#x27;re not capable of making something twice as fast if only you cared or had the time. If you haven&#x27;t done it as a constant exercise, you can&#x27;t.
评论 #35729345 未加载
评论 #35729141 未加载
评论 #35729008 未加载
评论 #35736946 未加载
评论 #35736937 未加载
theptipabout 2 years ago
Ironically, this article sets up a strawman of people who claim performance NEVER matters, and then rants long windedly in a tone suggesting it always matters.<p>My general principle: don’t give uni-directional advice when optimizing a u-shaped loss function.<p>I usually find that those failing to advocate the nuanced position “you can spend too much AND too little time on perf, here is how to prioritize” are not adding useful information to the conversation.<p>The truth is, most startups don’t need to worry much about perf. It’s a feature that your customers don’t usually ask for at first. At the other end of the scale, giant companies invest huge sums in taming performance. And your own situation will have more parameters than just that one simplified spectrum.<p>Measure ROI honestly, and prioritize accordingly!
评论 #35729664 未加载
评论 #35732387 未加载
评论 #35734912 未加载
评论 #35741639 未加载
klodolphabout 2 years ago
Also note that “Facebook reduces the storage it needs to store user photos by 50%” is something that contributes, like, nine-figure dollar savings to the bottom line. Facebook does all sorts of crazy stuff to improve performance–I don’t think many people who work there understand how the javascript bundler works, for example. It’s a lot more than something like WebPack.
tmtvlabout 2 years ago
I like the positive message he leaves us with: the barrier to entry for good performance is as low as it&#x27;s ever been. You can get good performance without needing hand-coded assembly SIMD vector optimizations.
评论 #35723705 未加载
ftxbroabout 2 years ago
So the biggest tech companies in the world, now that they are huge, are making their programs faster. OK. To me, that says maybe the reason they beat their competition to becoming huge, was that they wrote a lot of features quickly and didn&#x27;t nitpick about performance. Maybe the ones that wrote efficient high performance code from the start stayed small or were out-competed.
评论 #35724040 未加载
评论 #35724451 未加载
cratermoonabout 2 years ago
The author doesn&#x27;t really debunk any of what he calls &quot;excuses&quot; when he jumps immediately to Facebook, then Twitter, Uber, Netflix, and Microsoft. Those are companies with <i>huge</i> scale problems. He even says as much, near the end, claiming &quot;the evidence against these excuses comes from some of the largest and most financially valuable companies in the world&quot;. Nobody is arguing that performance doesn&#x27;t matter at those scales.<p>Here&#x27;s the author&#x27;s five points, and how at least one of the examples he gives <i>proves</i> the reasons.<p>No need. These companies operate on the leading edge of hardware performance, on purpose. They can&#x27;t just go out and buy faster hardware, it doesn&#x27;t exist. Google even builds their own, just to optimize for their uses.<p>Too small. Again, at the scale of Facebook or Netflix, a 5% performance gain translates to an enormous advantage, which leads directly to the next point.<p>Not worth it. Here again, we&#x27;re talking about saving millions of dollars but only because the systems are so enormous.<p>Niche. Facebook, Twitter, Netflix, and Uber&#x27;s performance needs are a niche of their own.<p>Hostpot. Here we can get to a specific example the author quotes. &quot;Cutting back on cookies required a few engineering tricks but was pretty straightforward; over six months we reduced the average cookie bytes per request by 42% (before gzip). To reduce HTML and CSS, our engineers developed a new library of reusable components (built on top of XHP) that would form the building blocks of all our pages.&quot;<p>So their Facebook <i>does</i> have a hotspot, it just happens that it&#x27;s a very large spot on a colossal size system.<p>Finally, the author says, &quot;If you look at readily-available, easy to interpret evidence, you can see that they are completely invalid excuses, and cannot possibly be good reasons to shut down an argument about performance.&quot;<p>I&#x27;m still looking for the evidence.
devjababout 2 years ago
Performance matters, but I’m not sure people are saying that it doesn’t. I’m not a performance “first” type of programmer by any means, but I always keep it in the back of my mind, what I also tend to keep in the back of my mind is cost.<p>I recently “inherited” a couple of back-end services when a developer left our company. It turned out that the code was terrible and that they haven’t used, any, or our helper tools. Since we use Typescript everywhere ignoring our quite opinionated and a little fascist linter rules is almost impossible, but the developer in question had the authority to turn it off, which they did and in doing so shot themselves completely in the foot. The back-end services were developed in JavaScript more than Typescript and since both our linters and usual teat pipelines were disabled, and since it’s software that has been developed over almost a years worth of changes, it was just horrible. We’re talking loops comparing values, that were probably there once but are now just sorting things as undefined === undefined kinds of terrible.<p>The performance was also atrocious. Basically what the service did was gather info on a couple of thousand projects and link them with tens of thousands documents in Sharepoint, but because it was build wrong, it wasn’t pulling the correct documents and it was taking 5-10 minutes each run time. It’s now running at around 10 seconds for its complete run time. Which is a massive performance improvement, and it’ll be even better once I finish building the cashing. So you might think I’m inclined to agree with the article, but I didn’t rewrite it because of its poor performance, I rewrote it because it didn’t work correctly and the performance gains were simply a happy “coincidence”.<p>This is because the performance didn’t really matter. Yes, it was costing us at most $77 a over our 3 year Azure contract, but the time I spent rebuilding it cost the company almost exactly $1500. Those $1500 were well spent because it wasn’t working, but would they have been well spent in terms of performance? Not really. That being said, it wouldn’t take a lot of those services to become expensive, so it’s not like the author is really wrong either. It’s just that I’m confused with whom he is arguing.
评论 #35724413 未加载
评论 #35723998 未加载
评论 #35727574 未加载
db48xabout 2 years ago
&gt; So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 MBs off the total machine code size and bought us enough runway to keep development going.<p>Wow. You know you have made bad choices when you need a desperation play like that.
typonabout 2 years ago
I kind of wish Casey would stop making these videos. I&#x27;m being completely serious when I say that this kind of knowledge and mindset gives you pretty much a superpower in the industry. Everywhere I go people think I am amazing, even though I just know a few things about performance and low level programming (like, enough to be amazing for &quot;mere mortals&quot;, but someone at RAD would snicker at my knowledge). If the industry doesn&#x27;t care, it&#x27;s simply a competitive advantage for you as an individual.
评论 #35720922 未加载
评论 #35727854 未加载
phendrenad2about 2 years ago
&gt; a situation that sometimes happens does not support the use of a statement as a blanket excuse<p>I feel like pointing this out has become table stakes in any conversation anywhere. Thinking of printing it out on a card and carrying it around.
globalresetabout 2 years ago
Scale &#x2F; data set size tends to expose performance issues. But that&#x27;s a good problem to have.<p>Yes, it would be great if all developers could write performant code, but let&#x27;s face it - there&#x27;s only so many hours in a day and days in a week. Developers already struggle to keep up with all the required knowledge. It&#x27;s not that people don&#x27;t want to be competent. We&#x27;re building more and more complex things while expanding the number of people employed building software which means average skill level is probably slightly decreasing.
评论 #35724320 未加载
评论 #35723558 未加载
评论 #35723689 未加载
评论 #35724138 未加载
Animatsabout 2 years ago
Do you want to reduce your compute costs, or improve the user&#x27;s perceived response time? Those are quite different problems. They&#x27;re approached in very different ways.
denieusabout 2 years ago
I agree performance is important and we should aim to improve it if we can, but the cost x benefit of these improvements must be evaluated. It&#x27;s easy to believe we&#x27;re making huge gains when there&#x27;s actually little gain added overall.<p>Two examples:<p>1. I&#x27;ve seen people mentioning that following good programming practices make the code slower, and by removing them you can have improvements around 40%. That sounds like a great number, until you realize the real bottleneck are other things (e.g. database queries, network latency, etc). When you calculate the overall improvement for the request, the gains are negligible.<p>2. There are some frameworks that market themselves as crazy fast: &quot;If you use us your app will boot almost instantaneously!&quot;. Looks cool, until you realize that a good pipeline will gradually rollout a new version and this will take time. Usually it comes with monitoring the new version for a while and then after it&#x27;s deemed healthy we switch versions completely. Now instead of waiting a few minutes + 10 seconds, you will wait only a few minutes, which doesn&#x27;t make much difference.<p>Performance gains will come with tradeoffs and, before committing to that, it&#x27;s a good idea to evaluate what are the real benefits of doing the changes we&#x27;re planning to do.
yen223about 2 years ago
It bothers me that all the examples provided shows that companies care about performance (&quot;Company $X made their app 20% faster&quot;), but none of them talks about the <i>impact</i> of caring about performance (&quot;Company $X made their app 20% faster, and saw a 200% increase in revenue as a result&quot;)
评论 #35724496 未加载
DeathArrowabout 2 years ago
I wonder what Casey thinks about using Javascript frameworks like Electron or Mobile Angular UI for everything, including desktop apps and mobile apps.
hosejaabout 2 years ago
Facebook seems(ed ~10 yrs ago) like such a great engineering company. Too bad they make Facebook.
tomgpabout 2 years ago
I’ve never seen anyone make the argument that performance is not important. I have seen people make the argument that performance is less imprtant than some other property (maintainability, extensibility, legibility etc. etc.) given certain aims and constraints.
评论 #35724402 未加载
评论 #35724431 未加载
paul_grishamabout 2 years ago
Obviously performance matters, it&#x27;s just a question of opportunity cost. The article just takes some absolute statements about performance not mattering and argues against them, which is obvious and pointless. They ignore that the benefit&#x2F;cost ratio for Facebook&#x27;s performance improvements is vastly different to that of the average software company with tens of employees and some SaaS CRUD app. Their own example of Uber&#x27;s app rewrite due to their previous architecture not being good enough is an example against their point - they got to where they were with imperfect architecture, then later fixed it once the opportunity cost tradeoff made sense.
评论 #35722597 未加载
naught00about 2 years ago
What is funny is many of the exact excuses were made in this thread: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34966137" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34966137</a>
评论 #35724532 未加载
leoncaetabout 2 years ago
Casey does it again.
joseph_grobblesabout 2 years ago
I once was brought into a team that fervently bought into the &quot;hotspot&quot; argument, blustering ahead under the notion that performance was tomorrow&#x27;s problem where someone would spend a day with a profiler and it would all be fixed.<p>In reality their project was death by a thousand...neigh million or billions...of cuts. Poor technology choices. Poor algorithm choices. Incompetent usage (e.g. terrible LINQ usage everywhere, constantly). This was the sort of project where profiling was almost impossible because any profiling tool barfed up and gave up at every tier.<p>Profiling the database was an exercise in futility. Profiling the middle tier was a flame graph that was endless peaks. Profiling the front-end literally crashed the browser. I ended up having to modify Chromium source to be able to accurately get a bead on how disastrously the Angular app was built.<p>This is common. If performance doesn&#x27;t matter to a team, it will never be something that can be easily fixed. Maybe you can throw a huge amount of money at the problem and scale up and out to a ridiculous degree for a tiny user base, but making an inefficient platform efficient is seldom easy.
draw_downabout 2 years ago
Is there no performance gain that’s small enough to be not worth it? If there is, then we’re just haggling over where the line is. If there truly isn’t, well, enjoy that! Because you won’t be shipping.
xupybdabout 2 years ago
The author fails to make the business case for their arguments. Performance tuning costs money. Don&#x27;t spend money with no expected ROI.<p>Yes at Facebook with end user facing software it is crucial to get performance right. If you&#x27;re running payroll at a 3 person company it doesn&#x27;t matter if the software is inefficient. Most of the time it&#x27;s Excel, and that is not the most efficient way to do those calculations. But it&#x27;s not worth investing in a better solution until processing payroll is a problem.