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

471–480 of 932 posts

Re: “Clean” code, horrible performance

#471

Post by mattgreenrocks »

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.

It’s less about accidentally writing n^2 sorts and more about not accidentally creating n^2 algorithms.

Re: “Clean” code, horrible performance

#472

Post by eyelidlessness »

TeMPOraL wrote: post #447
Turskarama wrote: post #357

Earlier quoted context omitted.

This is not my experience at all, at my org we always write it the simple way first, and if it needs more performance after the fact then we always add the performance. User friendliness always comes first. This includes not waiting 20 seconds for a db query that could be rewritten to happen in 1 second, but it also means not waiting a month for a bugfix which could happen in a day with maintainable code.

That's a nice approach, and I envy you the environment you work in. In my experience so far, it's typically the case that the 20 second DB query will annoy people for months or years - it won't get solved until enough people raise enough of a stink that someone finally prioritizes it. A large customer suddenly starting to make vague hints about bad performance is sometimes (but not always) helpful. Some may say that…

> In my experience so far, it's typically the case that the 20 second DB query will annoy people for months or years - it won't get solved until enough people raise enough of a stink that someone finally prioritizes it.

Among the many things I’ve learned as a self taught dev: you can be the person who raises enough of a stink if you care a lot. It’s not a thing you want to invoke frequently, but it’s a thing you very probably have power to invoke where it matters most. If you can make a good business case (or any case for user success that impairs your org), you have very good odds of being able to pursue it in any but the most toxic situations. If you can link $thing-you-want-to-pursue to other probably shinier biz/org goals, you’re 99% of the way there.

Re: “Clean” code, horrible performance

#473

Post by yCombLinks »

scotty79 wrote: post #264
Cthulhu_ wrote: post #220

Earlier quoted context omitted.

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…

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.

Correctly is covered by make it work

Re: “Clean” code, horrible performance

#474

Post by jiggawatts »

xupybd wrote: post #358
jiggawatts wrote: post #334

Earlier quoted context omitted.

> CPU cycles are much cheaper than developer wages. Please just stop with this. It's plainly false. At $dayjob I recommended some simple database query tuning that 1 developer applied in their spare time. This improved performance from 9 seconds per page to 500 milliseconds per page. That customer wanted to use auto-scale to expand capacity (nearly 20-fold!) to meet the original requirements, which would have cost ab…

In this case you have massive scale so a small amount of developer time can equate to a big reduction in CPU cycles. Those are the constraints you work with. Those are the business problems you are solving. So yes this was justified. It was justified on the numbers. My point is that your job is only to tune performance iff there is a solid business case for it. I spent a week reducing a pages load time because the bu…

It's not a massive scale at all! It's just "Enterprise" edition software (SQL Server, etc...) that costs $$$ to scale up.

The actual production platform is just a dozen or so virtual machines, they're not even that big.

Not everybody has their own data centre where they pay cost-price for all-Linux servers that run only free software.

In a typical business that hosts their servers in the public cloud, it's not unusual for a single database index to allow savings of tens of thousands a year.

E.g.: SQL Enterprise on an Azure E8bds_v5 VM is $2,678 per month, but the next step up to E16bds_v5 is $5,355 per month!

If you can optimise a database so it can move from 16 vCPUs to 8 vCPUs then that alone saves $32K annually. This is ignoring ancillary costs such as the second DR instance, etc...

Re: “Clean” code, horrible performance

#475

Post by thescriptkiddie »

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…

In my experience, software has been getting slower faster than hardware has been getting faster. Bringing focus back to performance would be a welcome improvement.

Re: “Clean” code, horrible performance

#476

Post by Gluber »

sarchertech wrote: post #261
Gluber wrote: post #244

Earlier quoted context omitted.

You are confounding three separate skills. Finding the right abstractions is an art, whether you write clean code or not. Writing high performance code is another art. A really good developer writes clean code using the right abstraction (finding those tends to take the most time and experience) and drop down to a different level of abstraction for high performance areas where it makes sense. The fact that bad develo…

If there are no hard measurements I can use to determine the value of "clean code" then I fall back on the results of produced by people who say they are writing clean code. There is no realistic way to objectively measure coding styles completely isolated from the people writing the code. I personally haven't seen value from that coding style. There may be some platonic ideal clean code that is better than other met…

I agree but i think that mostly comes from Clean Code being kind of required reading for junior developers, that lack the experience to understand those concepts in context. No methodology is perfect, and there are always cases where one needs to break out of them, to know when to do that comes with experience.

For juniors which have no experience, any sane methodology is better than none, since otherwise you get even more of a mess.

That said, Clean code has some great advice, some mediocre advice and some frankly bad advice, but the authors point are largely irrelevant to 99 % of software engineering.

Re: “Clean” code, horrible performance

#477

Post by xupybd »

alfalfasprout wrote: post #449
danuker wrote: post #283

Earlier quoted context omitted.

> and are very fast and reliable. Among the most popular languages is Python. It is popular in spite of its bad performance, high memory use, and lack of CPU multithreading. And it is heavily ran on servers. Why? Because running Python apps is still much cheaper than hiring humans to wait for calls or manage e-mails. Humans are valuable. They should not be working on easily automatable problems. The bottleneck is aut…

OK but... computationally heavy code in Python isn't generally really running in Python. Almost all of it either calls out to optimized C/C++/Fortran (eg; Numpy which in turn calls BLAS+LAPACK) or do that or some other separate compilation (eg; what ML libraries do with XLA, etc. or cython). Sure, python web servers are a thing. Heck, we use them a fair bit. But it's a deliberate decision from the start where it make…

>But it's a deliberate decision from the start where it makes sense to use it for that purpose.

Exactly that!

There is a time and a place for performant code but it's not the only metric we need to take into consideration. Sometimes you're better off using the slower tool or algorithm as it improves things on a dimension other than performance.

Re: “Clean” code, horrible performance

#478

Post by xupybd »

halayli wrote: post #440
xupybd wrote: post #219

>It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier. Our job is to write programs that run well on the hardware that we are given. If this is how bad these rules cause software to perform, they simply aren't acceptable. That is not our job! Our job is to solve business problems within the constraints we are given. No…

Sounds like someone stuck in their bubble.

This is exactly the point. Each bubble has different goals.

For example: The finance industry heavily uses Excel the inefficiencies this brings to performance are huge. However, the ability to get a domain expert to maintain the 'code' is worth it.

There are always trade offs. Even if you are in a performance sensitive industry your job is still not to write the most efficient code possible. You are there to make the best use of the resources you have to produce the best product you can. Sometimes that will mean doing things that harm performance but help in other ways.

Re: “Clean” code, horrible performance

#479

Post by Aeolun »

TeMPOraL wrote: post #324
jimbob45 wrote: post #291

Earlier quoted context omitted.

Well said. The aphorism "Premature optimization is the root of all evil" is meant to mean "Build it right first, then optimize only what needs to be optimized". There's really no need to start cooking spaghetti right off the bat. Clean code with some performance tweaks will be more maintainable in the long run without sacrificing performance.

Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen. There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat th…

> Casey's implied point is that clean code is already sacrificing performance from the start.

Where our opinion seems to diverge is where I accept that as being fine, for the sake of being clean/legible/understandable.

Re: “Clean” code, horrible performance

#480

Post by Aeolun »

GrumpySloth wrote: post #400
Aeolun wrote: post #351

Earlier quoted context omitted.

> If there's something wrong with that advice, I can't imagine what it is... It will start getting really annoying when you try to add shape ‘hexagon’ and need to figure out all the places where a shape can potentially be used, just so you can update the switch statements.

Even in C compiler will emit warnings for unhandled cases in switch statements as long as you don’t provide a default case (as you shouldn’t).

Depends on your language I suppose. I haven’t worked with a ton of compiled languages.

But we can just re-up the problem by adding 100 different shapes instead of the one. Now you have switch statements with 104 cases each spread through your codebase.

Post reply on HN