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

621–630 of 932 posts

Re: “Clean” code, horrible performance

#621

Post by dragonelite »

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…

This is so true especially when it comes to frontend development also for backend framework but to a lesser extend.

But i also think that the product, library or framework owner should really box in its project and reject wild growth of features and prevent generalisation of the usage.

Re: “Clean” code, horrible performance

#622

Post by mpweiher »

mpweiher wrote: post #51
vrnvu wrote: post #45

Earlier quoted context omitted.

> TDD is a good tool for enforcing that, as you only get to write code that you have a failing test case for. TDD encourages the use of mocks and unit testing to increase code coverage. And unit testing is specially dangerous. You write a test, then program, so the test is helping you (the programmer). Selling the idea that the higher the test code coverage is the better and safer your code is. Not true at all. If yo…

> TDD encourages the use of mocks and unit testing to increase code coverage. No, it encourages reasonable decoupling, i.e. good design. If you see yourself introducing mocks (I think you mean stubs, mocks are something more specific) everywhere, you are feeling the pressure, but avoiding the good design. https://blog.metaobject.com/2014/05/why-i-don-mock.html > Most unit tests are written to ease the development. Ye…

> guardrails against regressions.

And of course that's important because it enables you to be courageous and refactor mercilessly. Which again is important because it enables you to Do the Simplest Thing That Could Possibly Work, and stick to YAGNI, because you know you can change your mind later.

Re: “Clean” code, horrible performance

#623

Post by izacus »

ilyt wrote: post #249
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…

> 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. CPU meter when clicking anything on "modern" webpage proves that's a lie. Also, sure, even if "clicking on things" is maybe 1-5% vs "looking at things" THAT'S THE…

Yeah, this comment doesn't even pass a smell test as soon as you try any of the modern Electron "apps".

It's all horribly performing turd that needs a 4000$ MacBook to be tolerable at best.

Re: “Clean” code, horrible performance

#624

Post by rrobukef »

Tomis02 wrote: post #575
rrobukef wrote: post #352

Earlier quoted context omitted.

I do. Because I was asked to add a convex polygon and calculate its area. And now the shape_union must be rewritten from scratch. ... And maybe we want set-operations in the future...

> And now the shape_union must be rewritten from scratch. We spend most of our time reading code. If the Casey's code snippets are easier to reason about (which they are, especially as the codebase get larger), that's a big win. I'd imagine you want to optimize for code that is easy to (re)write, rather than minimize the number of key strokes while increasing the time spent understanding the code.

I'd say that the needing rewrites is bad for the future clarity of the code. So much so that people conclude the 50% performance hit is worth it to use open polymorphism (interfaces, etc.) over closed (tagged unions, algebraic data types, etc.). So I optimize for the ability to reason about over the lifetime of the project above the current ability to reason and above performance (with exceptions).

What is adding a polygon going to do? Either back to the 'bad' interface to hide variable object size, extend to a tagged union with a size of the biggest datastructure - hurting cache performance each time it grows -, or an involved Object of Arrays structure - not good for clarity but great for performance.

All while having to remember which field, width or height, to use for the circles radius.

Re: “Clean” code, horrible performance

#625

Post by xupybd »

jiggawatts wrote: post #612
xupybd wrote: post #532

Earlier quoted context omitted.

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

That's a totally different scenario.

Imagine it's all Linux no back up required and the database server has lots of capacity.

The lone developer can do it in half a day. No extra cost.

But yes there exist situations where that is no possible. This is just one example of where it is

Re: “Clean” code, horrible performance

#626

Post by Ultimatt »

This problem feels like a no runtime type problem. Highly dynamic languages have tonnes of grim problems like this, that they have to deal with because there is no good type information anywhere so stats at runtime is how you optimise. Raku for example has a lot of specialising runtime optimisations where all the virtual function calls get specialised and become dynamic by exception when the VM executes code.

Re: “Clean” code, horrible performance

#628

Post by simplotek »

xtian wrote: post #528
engineeringwoke wrote: post #501

Earlier quoted context omitted.

Re-renders are incredibly cheap in the big picture. They are not a source of performance bottlenecks in 99% of real world applications

So why do 99% of real world applications run like garbage? What’s the culprit?

> So why do 99% of real world applications run like garbage?

If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen.

The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand to improve some edge cases? Yeah, why not? Is it worth to pay people to spend time with a stopwatch at hand to shave off these milliseconds? Not really. It's all about tradeoffs, and there is no real world payoff in wasting developers' time to shave off that millisecond here or there.

Re: “Clean” code, horrible performance

#629

Post by DeathArrow »

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…

I wonder if you ever used Slack or Microsoft Teams and find them fast and reliable.

Re: “Clean” code, horrible performance

#630

Post by 22289d »

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…

Did you read the title? He's addressing performance.

And you're saying for many developers, performance is not the biggest priority.

That's fine. But it doesn't make him even 0.000001% wrong. And he's not applying anything to any niche situations. You just missed his point. Performance.

Post reply on HN