Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Clean” code, horrible performance

computerenhance.com

Post reply on HN
Print view View original

631–640 of 932 posts

Re: “Clean” code, horrible performance

#631

Post by Ultimatt »

praptak wrote: post #605
sangnoir wrote: post #453

Earlier quoted context omitted.

> The same thing is happening at bigger companies, at some point productivity start to matter and off the shelf solutions start to fail This is perhaps the third time I've posted this on HN, but what you describe is the circle of life for widely-used software projects. Large tech companies are not immune to it, resulting in frequent component rewrites, deprecations and almost-drop-in replacements that shuffle complex…

See Phoenix browser, now Mozilla Firefox.

Oh man Phoenix those were the days, 2003. I imagine a lot of HN readers here were only just born.

Re: “Clean” code, horrible performance

#632

Post by DeathArrow »

kyralis wrote: post #353
jiggawatts wrote: post #322

Earlier quoted context omitted.

Casey makes the point that you don't have to hand-tune assembly code, but instead just write the simpler code . It's easier to write, easier to read, and runs faster too! If there's something wrong with that advice, I can't imagine what it is...

"Easier to write, easier to read" is the part that's wrong with that advice. It absolutely is, on toy problems like the one described in the article. It very frequently is not when embedded in much larger domains as part of large projects maintained over years by teams.

Do you have any example of an open source project written in the simple style suggested by Casey Muratory that is very difficult to be maintained and you think would benefit from using "clean code", "SOLID", design patterns and abstraction on top of abstractions?

If you can't point to an actual example, I don't think you have a solid case.

Re: “Clean” code, horrible performance

#633

Post by m_mueller »

Cthulhu_ wrote: post #220
mabbo wrote: 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…

An oft recited of thumb: Make it work, make it pretty, make it fast - in that order. That is, performance bottlenecks are easier to find and fix if your code is clean to begin with. I sometimes wish performance was an issue in the projects I work with, but if it is, it's on a higher level / architectural level - things like a point-and-click API gateway performing many separate queries to the SAP server in a loop wit…

Here is the thing: The paradigms of your initial design, or if you're in a better situation, the first refactor, is likely to stay. If performance is what you think about last, you choose different paradigms (like e.g. polymorphism). From my experience, a winning strategy is to think about things that scale already in the initial design, and what scales in a backend-system is often the amount of data you want to pipe through it. Thus, keeping it data centric (primitive types and arrays for raw data), while using polymorphism and functional interfaces to keep the methodologies clean, is usually a good idea.

So, most code that I write tends to have dead simple data types, but combines it with classes (and subclasses) that represent methods (strategies) on how to retrieve, transform, present and store the data. The 'make it work' phase may do this in a simple script, but the actual data model tends to stay the same.

Re: “Clean” code, horrible performance

#634

Post by noobermin »

rileymat2 wrote: post #558
noobermin wrote: post #536

Earlier quoted context omitted.

The fact that you think that "everything is inside a tight loop" doesn't apply to all code today already shows your own model of code is broken because you believe the syntactic sugar modern programming languages and paradigms provide is actually reality. If everything wasn't in a loop, your program would halt once you're done with whatever you're calculating. Just because you have things like callbacks and things fe…

You dropped the word "tight", it is important.

How so? What loop isn't "tight"?

EDIT: To expand on this, why is modern software slow? The reason is because people, thinking their code isn't a bottle neck or performance doesn't matter but adherence to the right abstractions is, they write slow code and call backs thinking everything just happens immediately, with layers of abstractions, and those little innocent steps add up when every piece of code written today is written with that same neglect. The call backs runs slowly, queues fill, promises hang, and so-on and on we go.

So sure, may be your code doesn't seem like it needs to run at 60fps. But when everything I do on a computer is written like it will be run every 10 seconds, it definitely will be noticeable. That's because I don't just run your program or look at your website, I look at 10 of them or even more. If I average all of those per time, then may be your code should in fact be able to run at 1Hz or so or I will start to notice.

People of course were right not to teach new devs not to over-optimize immediately, but the culture has swung so far in the other direction, especially since you all seem to love complexity so much, you've managed to yes make computers that can calculate pi faster than a super computer from the 70s crawl when it renders and handles an editable textbox. There has to be a move back in the other direction, you guys need to give a shit about performance, at least a little.

Re: “Clean” code, horrible performance

#635

Post by boredhedgehog »

badsectoracula wrote: post #371
fvdessen wrote: post #319

Earlier quoted context omitted.

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.

If your profiler doesn't show any hotspots (which is incredibly rare in practice) and your program is still slow, it means you can simply pick any of whatever functions/methods show up near the top to optimize. If your program isn't slow then you don't need to bother making it any faster. Even Michael Abrash, who specializes in code optimization, once explicitly wrote in his graphics programming black book that "The…

> If your program isn't slow then you don't need to bother making it any faster.

But you can only judge that for the very limited set of hardware you personally have access to. You might have many users -- or potential users -- with slower CPUs.

Re: “Clean” code, horrible performance

#636

Post by fredrikholm »

iamcreasy wrote: post #568
fredrikholm wrote: post #4

I've worked in projects where no one seemed to know SQL, where massive speed improvements were made by fixing very low hanging fruits like removing select * queries, adding naive indexes, removing N+1 queries etc. Likewise, I've worked in code bases where performance had been dreadful, yet there were no obvious bottlenecks. Little by little, replacing iterators with loops, objects/closures with enum-backed structs/ta…

> I've worked in projects where no one seemed to know SQL, where massive speed improvements were made by fixing very low hanging fruits like removing select * queries, adding naive indexes, removing N+1 queries etc. Can you recommend any SQL book with main focus on performance improvements like this?

I've learnt as I've needed it, so I'm afraid I don't have a single source to point at. Of the things that I've listed, a quick google search on each should give you enough info to be useful.

> Select * queries

Sometimes you only want two columns, but you ask for 5. Say you query a million rows, where you ask for but throw away 60% of all the data you get back.

> Naive indexes

As in, just slapping an index on a table that doesn't have one makes such a big difference that sometimes it's all you need.

> N+1 queries

This is more of a problem in ORMs, but any time you call the database N times instead of 1 time. A classic example is writing a for loop that asks for one row at a time, instead of asking for all rows once.

Re: “Clean” code, horrible performance

#637

Post by DeathArrow »

yashap wrote: post #263
mabbo wrote: 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…

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…

Maybe for low user count is valid. We run a large multitenant, microservice based application and the physical machines where the Kubernetes pods reside have their CPUs at 90%. The application makes such a large use of "clean coding", "design patterns", SOLID that would make Uncle Bob proud. We would have been better without using so much abstractions on top of abstractions.

Re: “Clean” code, horrible performance

#638

Post by loup-vaillant »

rerdavies wrote: post #554
loup-vaillant wrote: post #491

Earlier quoted context omitted.

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 dec…

You need to do some research on how to get modern C/C++ compilers to vectorize.;-) No assembly required, and not that hard to restructure code. (But MUCH easier in C++).

I tried auto-vectorisation, and it worked pretty well. But the code became just as big as using intrinsics would have (that with explicitly unrolling loops and rearranging things in memory), and intrinsics generated code that was easily 35% faster.

I decided not put it off for later, and keep things simple for now.

Re: “Clean” code, horrible performance

#639

Post by tysam_and »

sangnoir wrote: post #453
teki_one wrote: post #318

Earlier quoted context omitted.

The thing that sets him off is that he is using a computer with enormous computing power and everything is slow. He does have a narrow view, but it does not make his claims invalid. I liked that his POC terminal made in anger made the Windows Terminal faster. But even in that context it was clear that by making some tradeoffs - which the Windows Terminal team can not make (99.99% of users do not run into the issue, b…

> The same thing is happening at bigger companies, at some point productivity start to matter and off the shelf solutions start to fail This is perhaps the third time I've posted this on HN, but what you describe is the circle of life for widely-used software projects. Large tech companies are not immune to it, resulting in frequent component rewrites, deprecations and almost-drop-in replacements that shuffle complex…

I've started a project that has the potential to go down this path but have a very strict 'implement your own diffs if you want them' for this particular project.

Like, feel free to fork away if you like. The core repository needs to be simple and stay true to its goals, and when it updates everyone downstream can update if they want to do that to themselves. But for what it is and does, maybe the project as it is is good enough.

I start feeling almost physically sick when I see the potential for bloat to creep into the software I write. This makes working with scaled software development with others particularly hard, however.

Re: “Clean” code, horrible performance

#640

Post by oleg_antonyan »

GrumpySloth wrote: post #364

This thread is, predictably, another demonstration of conflating optimisation with being aware of performance. The presented transformation of code away from “clean” code had nothing to do with optimisation. In fact, it made the code more readable IMO. Then it demonstrated that most of those “clean” code commandments are detrimental to performance. So obviously when people saw the word “performance”, they immediately…

Despite being based on science, software development is full of bs, opinions and lacks measurable metrics. How "clean" this code is? In numbers between 0 and 1 for example. What's the metric there? Does using polymorphism automatically make your code clean? We cannot reliably reason about even single responsibility b/c there's no real measure how to count responsibilities of a function. In such la-la-land some desperately seek any formal measure, and there's one - performance - you can actually put a number on a piece of code. But you cannot do this for code "cleanliness". So some people prefer to ignore unmensurable trait and replace it with measurable
Post reply on HN