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

551–560 of 932 posts

Re: “Clean” code, horrible performance

#551

Post by Turskarama »

yuliyp wrote: post #412
Turskarama wrote: post #360

Earlier quoted context omitted.

Testing, do you not do testing? Use the software. If it seems slow drill down and find the critical path and optimize it.

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.

Re: “Clean” code, horrible performance

#552

Post by jimbokun »

Veliladon wrote: post #505
gardenhedge wrote: post #419

Earlier quoted context omitted.

I'd be interested in a blog post on this. Why is JS map so much slower than a for loop?

So normally when you do a bunch of patterns of .filter(), and/or .map(), and/or .reduce() on an array in most other languages the compiler will normally iterate through the elements doing whatever you requested at each element. No allocations, one quick trip through the entire working set, cache locality works no matter how big the set is. In JavaScript on the other hand it handles the abstraction by constructing a s…

Interesting. Is there something about JS semantics that prevents JS engine writers from better optimizing that pattern?

Re: “Clean” code, horrible performance

#553

Post by jimbokun »

onion2k wrote: post #247
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…

For what it's worth, less than 4% of websites use React (approximately 4% use any JS framework) . If you believe the web is slow because of React you are wrong. It's not even due to JS.

Is that weighted for the traffic those web sites receive?

It could be that most of the traffic is served by websites using heavyweight frameworks, but the long tail of low traffic websites use them rarely.

Re: “Clean” code, horrible performance

#554

Post by rerdavies »

loup-vaillant wrote: post #491
simplotek wrote: post #456

Earlier quoted context omitted.

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

Re: “Clean” code, horrible performance

#555

Post by celrod »

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…

There was a fun example in the Julia compiler around a year ago.

Part of the compiler was O(N^2) in `let` block nesting depth. That is

  let x = foo(), y = y, z = 2y
    ...
  end
would be a depth of 3. It didn't seem like that should be a problem, N is never going to be 10, let alone 100, right?

Until suddenly, `N` was in the thousands in some critical generated code spit out by some modeling software, so that handling the scoping introduced by `let` suddenly dominated the compilation time...

Re: “Clean” code, horrible performance

#556

Post by whstl »

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.

As a counterpoint: "Clean Code", at least the variant from the book, is very frequently also extremely difficult to write or to read in larger codebases too.

The claim that "Clean Code" scales better or allows for more maintainable software hasn't been proven by anyone, and everyone with enough experience has worked with several counter examples.

The problem of code maintainability is not solved by this coding philosophy.

Re: “Clean” code, horrible performance

#557

Post by whstl »

jrumbut wrote: post #435
kyralis wrote: post #353

Earlier quoted context omitted.

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

And when you combine inadequate abstractions with programmers who aren't the kind of geniuses brought in to optimize game engines you get very difficult to fix performance problems. One of the nice things about some of the clean code concepts he uses is that (as he shows) you can tactically step back from them in key, performance critical areas and reap these wins. If you stay too low level you get lots of tangled sp…

I find it a bit disingenuous to call what Casey Muratori is doing "staying in the low level".

Using procedures/functions is not exactly "low level". Using switch is not low level. Lookup tables are something you have to do in high level code all the time.

Sure he could have used much better variable naming (CTable?) and probably documentation, but code-wise there's nothing that screams low level there.

Re: “Clean” code, horrible performance

#558

Post by rileymat2 »

noobermin wrote: post #536
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…

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.

Re: “Clean” code, horrible performance

#559

Post by yieldcrv »

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…

always be aware of the computational time. but also be aware of where the real bottlenecks are.

every place we work at is FAR more likely to scale how many compute instances we are using, than optimize the application.

Re: “Clean” code, horrible performance

#560

Post by whstl »

joaonmatos wrote: post #397
magicalhippo wrote: post #299

Earlier quoted context omitted.

Then again, thing's aren't in the critical path until suddenly they are. Regardless of scenario I will never willingly do a O(n^2) sort when writing new code. Just in case those 10 items suddenly turn to 10000 one day.

Are you even manually implementing sorts frequently? Even languages that are notorious for having tiny libraries, like C and JS, have built-in sorts.

Not sorting, but very simple algorithms that can't afford having O(n^2) performance? That's common even in CRUD apps.
Post reply on HN