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

561–570 of 932 posts

Re: “Clean” code, horrible performance

#561

Post by rerdavies »

heisenbit wrote: post #281
simplotek wrote: post #250

Earlier quoted context omitted.

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software o…

How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?

Profiling. If you're not profiling, you're completely wasting your time. The 1% is almost never where you think it is.

And when you do identify the 1%, you need to be testing optimizations with a profiler constantly while optimizing. Profile. Do some optimization. Profile again. Roll back if not successful. Repeat until done. It's impossible to optimize well if you're not doing profiling.

The ultimate tools would be either Intel's profiling tools, or ARM's profiling suite (both very expensive). But MSVC and GCC do a fantastic job of scheduling instructions to avoid pipeline stalls these days, so these deep profiling tools are unlikely to gain more than 2 or 3% performance increases these days. (Worthwhile pretty much only if you're writing GPU drivers for NVidia or AMD).

Taken as a given that 100% of your code is at least algorithmically correct in the first place. (Appropriately better than O(N^2) whenever possible).

- Former writer of graphics drivers, currently audio DSP engineer.

Re: “Clean” code, horrible performance

#562

Post by userbinator »

Related recent discussion about the actual Clean Code book: https://news.ycombinator.com/item?id=34843128

I prefer a much simpler rule: if it's easy for the CPU to execute, it's likely easy for you to read too. That means: no deep nesting, minimise branchiness (indirect calls are the worst), keep the code small and simple.

Re: “Clean” code, horrible performance

#563

Post by icedchai »

kyle-rb wrote: post #488
TeMPOraL wrote: post #369

Earlier quoted context omitted.

It's the same problem. Virtual calls are degenerate, in-process RPCs. Or put another way, the reason you make tons of RPCs is the same reason you make tons of virtual calls: you consider services or subclasses to be cheap, so you use them a lot to mold your systems to organizational/people problems instead of the thing the software is supposed to do.

IMO the main difference is that for ~98% of people writing code, subclasses actually are very cheap. The performance losses (11 cycles per iteration?) aren't enough to dissuade me from organizing my code cleanly.

It's more than performance. Some of the worst code I've worked on has had too many layers of sub-classes, making it difficult to navigate and a real loss to developer productivity. After a certain point, it becomes OO spaghetti or, more accurately, "lasagna." At more than 3 layers, you really need to stop and think if it's necessary.

Re: “Clean” code, horrible performance

#564

Post by zweifuss »

PragmaticPulp wrote: post #544
jiggawatts wrote: post #317

Earlier quoted context omitted.

Jira cloud famously takes 30-60 seconds on even a fairly high-end laptop, which is just staggering. I can install an entire operating system into a virtual machine in that time.

> Jira cloud famously takes 30-60 seconds on even a fairly high-end laptop, I use Jira every day and, no, it does not take 30-60 seconds to load a page. The hyperbole in this comment section is something else. Either that or people are using 15 year old computers to browse the web.

I see 30-seconds delays in a vanilla project on Jira cloud sometimes. Hardware was expensive in 2019.

Re: “Clean” code, horrible performance

#565

Post by Ygg2 »

pkolaczk wrote: post #154
Ygg2 wrote: post #108

Earlier quoted context omitted.

Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. Then you get people writing their own horrible hacks. Both clean code and performance oriented design have their extremes. Clean Code has Spring with Proxy/Method/Factory monster... and hyper performance has the extreme in the story of Mel (i.e. read-and-weep only code)…

> Sure, but what happens, once you want to start supporting other shapes other than basics? Sure, but what happens, once you want to start supporting more operations on the shapes?

Add more abstractions of course.

Re: “Clean” code, horrible performance

#566

Post by rerdavies »

Turskarama wrote: post #551
yuliyp wrote: post #412

Earlier quoted context omitted.

Testing is often not enough. Developers might have a few test cases with a few records, or a few other users. Real users might do more with it, and things which perform fine in testing suddenly turn into real performance bottlenecks when you're loading an order list with a thousand entries in it instead of two.

When I said testing that includes integration testing, not just unit tests. We do this exact thing with queries that are known to be complex, run them against databases the same size and complexity as real production databases. It's not hard.

Building representative databases is not straightforward.

If you're lucky enough to eat your own dogfood, run unit tests against a copy(!) of your in-house database. A utility to anonymize the data was a fairly significant investment, but absolutely worth it in the long run. Being able to run and monitor benchmark unit tests for selected critical operations on enterprise-scale test data as part of the continuous-build process: fabulous!

Re: “Clean” code, horrible performance

#567

Post by [deleted] »

TeMPOraL wrote: post #465
bcrosby95 wrote: post #401

Earlier quoted context omitted.

The moon doesn't fall into the ocean until it does.

Not a fair comparison :P. The point is that the developers may think O(n^2) is fine because their toy use cases had n=10...100, but then actual users will try to use the software for n=10k, or n=100k, and then either waste their lives working with suddenly slow software, or look for alternatives. I walked into a case like this the other day. I wanted to do a little semi-collaborative project planning. I found a nice…

[deleted]

Re: “Clean” code, horrible performance

#568

Post by iamcreasy »

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?

Re: “Clean” code, horrible performance

#570

Post by rerdavies »

commandlinefan wrote: post #236
mquander wrote: post #196

Earlier quoted context omitted.

> 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 performance calculation software then sure, go crazy, get those improvements. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because o…

Well, you can make things run even faster by hand-coding it in assembler... but performance isn't the reason we use high level languages. I agree with you that ignoring performance characteristics in favor of speed-to-market is an awful and pervasive practice in modern software development, but the linked article isn't talking about or making that case at all. He's saying that he can make his own custom object orient…

It's not really possible to write hand-coded assembler that's faster anymore. C/C++ compilers have deep knowledge of architecture-specific instruction pipelines that allow them to schedule instructions more accurately than any human could.

My most recent misadventure: trying to write hand-coded ARM Neon assembler, and/or C++ code with neon intrinsics to optimize a piece of real-time audio effect code. The clear performance winner: plain C++ with no intrinsics, but tweaked to allow auto-vectorization (plus judicious use of the __restrict modifier for a small but significant boost). GCC produced code that had better instruction scheduling than I could (but not for the NEON intrinsics, oddly). And as an added bonus, the same plain-old C++ code generates AVX vectorization on MSVC without modifications! (MSVC also supports __restrict until the C++ standards committee gets their act together to adopt the eminently necessary C99 restrict keyword).

Post reply on HN