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

611–620 of 932 posts

Re: “Clean” code, horrible performance

#611

Post by gregjor »

treis wrote: post #304
scotty79 wrote: post #264

Earlier quoted context omitted.

I heard it as make it work make it work correctly make it work fast Pretty was never in the picture. But if anyone wants to add it, it should come last.

I like Make it work Make it good Make it fast

I can measure "works" and "fast." Good can mean lots of things, it's a subjective assessment of code quality, readability, and maintainability. More experienced programmers probably have a better idea about how to achieve readable and maintainable code, but so far no one has come up with a measurable way to make code "good." Bob Martin spells out his ideas of "good" in his books but I don't find his examples particularly good, or even real-world. The only useful guide to "good" code I've come across in 40 years programming is The Elements of Programming Style, which Bob Martin has managed to expand from a thin pamphlet to multiple large books.

Re: “Clean” code, horrible performance

#612

Post by jiggawatts »

xupybd wrote: post #532
jiggawatts wrote: post #510

Earlier quoted context omitted.

> CPU cycles are cheap But people aren't. Any code that "makes people wait" is wasting people's time. The only way to make code take less time is to optimise it, because capacity != latency. You can't get a 20 THz processor. You can buy more capacity, but you can't buy more speed! At FAANG scale, it's common to hire "top" developers at hugely expensive annual total comp to tune stdlib code like "string" for just 1-2%…

>I can't think of a typical business scenario where compute and/or associated per-core-licensing costs can be blindly disregarded with a flippant statement like "developers are expensive and infrastructure is cheap". Say you're a small business with an in house server rack. Not a software company but say a manufacturing business. Not enterprise scale, smaller. You have 1 development resource. It turns out the ETL ser…

> moving the ETL onto the fresh server.

On which... it'll run at maybe 20% faster, because that's the scale of single-threaded processor speed improvements these days. Not to mention that now there's a network hop involved, which will eat into any CPU gains.

Very few apps scale well with increasing core counts, and then hit a wall around 64 cores for almost everything.

Okay, okay, fine. The ETL is natively parallel code and somehow, magically, it can read inherently sequential file formats like multi-gigabyte CSV or JSON files in parallel. This tiny org already has 10 gigabit switches, SFPs, and everything.

Did you upgrade the database server too? No? Now the shiny new ETL server is twiddling its thumbs while the database server is getting overloaded.

Suddenly this option is "not so cheap". You have to buy a new database server and... uh-oh... it's Microsoft SQL Server, Oracle, or SAP HANA, and the licensing is going to eat half your tiny little company's profits for the year.

Did you forget the OS license, backup agent license, anti-malware license, and so on? I bet you did. All of those are extra, and either per-machine or per-core.

Someone has to set this all up. Small non-IT shops typically outsource this to an IT service company. They'll explain all the extras that turn a $3K purchase into a $30K purchase (including on-site assistance to install everything).

Or that 1 guy could have just taken a 10 minute look at the ETL logs, discovered that "SELECT * FROM HugeTable" is unnecessary, and fixed the problem.

Re: “Clean” code, horrible performance

#613

Post by dmitriid »

paxys wrote: post #492
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.

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

> 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.

Of course it will.

If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.

Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.

Boom. You're operating close to the speed of light.

Re: “Clean” code, horrible performance

#614

Post by Agentlien »

p1necone wrote: post #293
yashap wrote: 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…

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems. I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true. Also the fact that…

This comment helped make sense of this whole comment section for me.

I work in game development, largely with optimisation. I mostly work with GPU optimisation, which is a whole different beast. On the CPU, most of the time issues are either trying to do too much stuff in a hot loop (rendering stuff that could have been culled, putting physics on objects that don't need it,...) or doing something in a slightly inefficient way in a hot loop. Because everything in the game is indeed a loop consisting of a series of hot loops.

People in this comment section call his example contrived, but it's very similar to one of the biggest performance improvements I've seen in practice.

Re: “Clean” code, horrible performance

#615

Post by theK »

Just keep in mind that actually keeping that 1.5x or even 10x performance boost you need to apply these consistently to a laaarge code base (performance critical apps tend to be this).

This means that in 2-3 months you end up with a codebase that is very difficult to work with, team members tripping over each other due to bad deps and abstractions and your iteration time start shooting up.

Doesn't seem like a realistic avenue to choose except maybe when coding to a final spec?

Re: “Clean” code, horrible performance

#616

Post by bandika »

I find it amusing that many corporate dev teams picks C++ for its performance / low levelness, but then reject any code that Casey's advocate for. It is extremely hard to convince them to consider these things (ie in this case cache misses and branch mispredictions).

Now, if we consider only a conservative 2x speed-up, I might not care if my app starts up in 2s or 4s, but I do care if my device's battery last for 20h v 10h.

Re: “Clean” code, horrible performance

#617

Post by drewm1980 »

p1necone wrote: post #293
yashap wrote: 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…

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems. I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true. Also the fact that…

New developers are still watching Uncle Bob videos online and taking those strategies as the default for how you craft code, largely because there are not very many people since then making similarly grandiose claims about how software should be crafted and forming entire companies pushing adoption of those techniques commercially. We even had a young dev leave our company and form a startup around the idea of doing what we do, but a full "clean code" rewrite. Our software already has major performance issues, I'm not hopeful about the speed of his code after he layers on even more abstractions.

Re: “Clean” code, horrible performance

#619

Post by moremetadata »

jiggawatts wrote: post #322
p1necone wrote: post #293

Earlier quoted context omitted.

Casey Muratori knows a lot about optimizing performance in game engines. He then assumes that all other software must be slow because of the exact same problems. I think the core problem here is that he assumes that everything is inside a tight loop, because in a game engine that's rendering 60+ times a second (and probably running physics etc at a higher rate than that) that's almost always true. Also the fact that…

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...

> It's easier to write, easier to read, and runs faster too!

ITs still possible to get a bottleneck in assembler.

Whatever language is used, executable code still needs to be profiled using tools as described here.

https://en.wikipedia.org/wiki/Profiling_(computer_programmin...

Re: “Clean” code, horrible performance

#620

Post by [deleted] »

l33t233372 wrote: post #535
kaba0 wrote: post #271

Earlier quoted context omitted.

Databases are often not used by a single entity, so while I am very interested in your experiences, I think it is a great specialization for certain problems, but is not a general solution to everything. All in all, I fail to see how it disagrees with my points.

> All in all, I fail to see how it disagrees with my points. I didn’t see any part of the comment that implied it did

[deleted]
Post reply on HN