Live data from Hacker News

“Clean” code, horrible performance

computerenhance.com

491–500 of 932 posts

Re: “Clean” code, horrible performance

#491

Earlier quoted context omitted.

I realised when I implemented EdDSA for Monocypher that optimisations compound. When I got rid of a bottleneck, I noticed that another part of the code was the new bottleneck, and some of the optimisations compounded multiplicatively . It took many changes before I finally started to hit diminishing returns and stop. All while restricting myself to standard C99, and trying fairly hard not to spend too many lines of c…

> I realised when I implemented EdDSA for Monocypher that optimisations compound. I feel you're missing the whole point. It's immaterial whether anyone can get to optimizations that compound multiplicatively. The whole point is that halving something that costs nothing earns you nothing. That's the whole point. Go ahead and shave off that millisecond. Will anyone actually notice whether you add or remove that penalty…

People did notice. Quite a few happy users are glad signature verification took less than a second instead of more than 3. Or 30, if you compare to some of the alternatives. Others love the fact it uses 2KB of stack space instead of 5.

Monocypher's speed was actually an important component in its success in the embedded market, even though I didn't explicitly target it initially (I was lucky my portability driven decisions made it a good fit there).

Re: “Clean” code, horrible performance

#492
post #263

Earlier quoted context omitted.

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…

If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.

All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. So sure, if you absolutely must optimize that 30ms call after you have fixed everything else then go ahead, but very few are at that stage or will ever get to that stage. And if you try to optimize that last 5ms at the expense of the much larger issues then you are actually making things worse.

Re: “Clean” code, horrible performance

#493
post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

[dead]

Re: “Clean” code, horrible performance

#494

What is the author suggesting? To write software using infinite loops changing global state? Makes sense for video games but not for the custom enterprise software where clean code practices are usually applied. The enterprise code must be easy to change because it deals with the external data sources and devices, integration into human processes, and constantly changing end-user needs. Clean code practices allow tha…

I work in IT, and I don't think I've ever used an "enterprise" software product and thought to myself, "hey, this is pretty responsive!"

Re: “Clean” code, horrible performance

#495
post #358

Earlier quoted context omitted.

In this case you have massive scale so a small amount of developer time can equate to a big reduction in CPU cycles. Those are the constraints you work with. Those are the business problems you are solving. So yes this was justified. It was justified on the numbers. My point is that your job is only to tune performance iff there is a solid business case for it. I spent a week reducing a pages load time because the bu…

It's not a massive scale at all! It's just "Enterprise" edition software (SQL Server, etc...) that costs $$$ to scale up. The actual production platform is just a dozen or so virtual machines, they're not even that big. Not everybody has their own data centre where they pay cost-price for all-Linux servers that run only free software. In a typical business that hosts their servers in the public cloud, it's not unusua…

Sure that makes a lot of sense, I'm sorry for my bad assumptions, but that drives my point home even more. The problem is not related directly to your performance on the hardware. It's an additional cost from the business environment. License costs can drastically alter where your efforts are best spent. I'd imagine there are times where you might be better off pulling huge chunks of data out of the database to process on machines that don't have such a big license cost.

CPU cycles are cheap, SQL Server licenses are extortionately expensive. While the costs are tied to the server they run on if you can offload to a different CPU not tied to that license model you can still take advantage of the low cost of CPU cycles.

Re: “Clean” code, horrible performance

#497
post #262
post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

I don't know man, my TV has hardware several orders of magnitude faster and more advanced than the hardware that took us to the moon, and it takes dozens of seconds for apps like Netflix or Amazon Prime Video to load dashboards / change profiles or several seconds to do simple navigation or adjust playback. People just don't know how to properly write software these days, universities just churn out code monkeys with…

So true and so annoying.

Re: “Clean” code, horrible performance

#498
post #347

Earlier quoted context omitted.

I’m always glad to save nanoseconds on my code so that we get the absolute best performance out of that 10s long call to the legacy API.

> I’m always glad to save nanoseconds on my code so that we get the absolute best performance out of that 10s long call to the legacy API. you're right. some things are inevitably slow so we should therefore never care about performance in any situation. avoid belittling the efforts here just because they don't apply to all situations.

I’m making a point, not belittling the ‘efforts’ here. Though I’m inclined to believe it didn’t take the author too much effort.

Re: “Clean” code, horrible performance

#499
My biggest confusion with the "clean code" concept is, what does clean mean? Such a vague concept seems to invite arbitrary bikeshedding over how many lines a function should have, whether comments are good, etc.

In a kitchen, clean is a pretty objective concept: no dirt or grime, objects put away with similar objects. Not sure what it means in code, but it seems many people have strong, conflicting, subjective opinions about it. Doesn't seem like a good recipe for productivity or alignment.

I feel like it would be wiser to limit the concept of clean to the eradication of obviously "dirty" or "cluttered" things, like inconsistent style, or naming a module in a way that is misleading about its contents or functionality. Just as all different kinds of buildings can be clean, a code of "cleanliness" should not be so comprehensively prescriptive about architecture and organization. Use more appropriate names for those dimensions of code quality, rather than "clean" as the single stand-in for every good thing.

Re: “Clean” code, horrible performance

#500
post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

> I think the author is taking general advice Not just general advice, but advice that is meant to be applied to TDD specifically. The principals of clean code are meant to help with certain challenges that arise out of TDD. It is often going to seem strange and out of place if you have rejected TDD. Remember, clean code comes from Robert C. Martin, who is a member of the XP/Agile gang. The author cherry-picking one…

But is this trade off not a little bit to much?

It reminds me of Twitter or other companies which starting to change programming languages for performance reasons.

Post reply on HN