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

181–190 of 932 posts

Re: “Clean” code, horrible performance

#181

Post by Johanx64 »

vborovikov wrote: post #139

What is the author suggesting? To write software using infinite loops changing global state? Makes sense for video games but not for the custom enterprise software where clean code practices are usually applied. The enterprise code must be easy to change because it deals with the external data sources and devices, integration into human processes, and constantly changing end-user needs. Clean code practices allow tha…

>The enterprise code must be easy to change because it deals with the external data sources and devices, integration into human processes, and constantly changing end-user needs. Clean code practices allow that, it's not about CPU performance and memory optimizations at all.

There are no good metrics that measure how "clean code" (atleast the given rules) make the code easier or harder to change and maintain.

All the Java style "enterprise type code" from my experience is bloated, full of boilerplate getters and setters and all sorts of abstractions that often make things harder and not easier to understand/maintain, etc.

However CPU performance is easy to measure, and sticking to "clean code" rules as given in the video demonstrably sets you back a decade in hardware progress/makes the code run 10x slower.

> Clean code practices allow that

This is what you believe, not something you can actually measure as far as I know

Re: “Clean” code, horrible performance

#182

Post by lightbendover »

stunpix wrote: post #150

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere "? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method…

> No one is working with a huge amount of data in big loops using virtual methods to take every element out of a huge dataset like he is showing.

Things way worse than that exist. Replace "virtual method" with "service call."

Re: “Clean” code, horrible performance

#183

Post by muricula »

Arnavion wrote: post #27
anonymoushn wrote: post #12

Earlier quoted context omitted.

I think "them" is someone named Robert Cecil Martin, but I'm not sure if this example from the video appears in his book. What compiler are you using that devirtualizes every class hierarchy? I suspect that Casey is using C++ so he may (unfortunately) have multiple translation units in his program.

>I suspect that Casey is using C++ so he may (unfortunately) have multiple translation units in his program. Yes, the video uses C++. Obviously if one compiles a library then the compiler has no way of knowing that other subclasses of `shape_base` do not exist. My point is that when compiling a binary as they are doing for their video, the compiler knows that there are no other subclasses that it needs to cater to. I…

To fix 2, add '-fno-rtti' to the args: https://gcc.godbolt.org/z/zMdfx71qE Unfortunately, gcc does not seem to devirtualize in your example

Re: “Clean” code, horrible performance

#184

Post by drivers99 »

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…

It still matters because in your example it will affect how smoothly the computer responds once it gets the user input.

Re: “Clean” code, horrible performance

#185

Post by FooBarWidget »

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…

Not only time to market, but also maintainability.

In non-performance-critical areas, it's pretty important that when the original dev team leaves, new hires can still fix bugs and add features without breaking things.

Re: “Clean” code, horrible performance

#186

Post by muricula »

Tomis02 wrote: post #130
Arnavion wrote: post #27

Earlier quoted context omitted.

>I suspect that Casey is using C++ so he may (unfortunately) have multiple translation units in his program. Yes, the video uses C++. Obviously if one compiles a library then the compiler has no way of knowing that other subclasses of `shape_base` do not exist. My point is that when compiling a binary as they are doing for their video, the compiler knows that there are no other subclasses that it needs to cater to. I…

Correct me if I'm wrong. Even if the compiler devirtualizes the classes, you still have the memory cost of storing the vtable pointer in each of the object instances (8 bytes for each instance), which means you need to do more fetches from memory. Does CPU prefetching negate the cost of these additional memory lookups?

The enum to tell what shape an object is costs something, probably 4 bytes. Storing the 8 byte vtable constant isn't so bad considering.

Re: “Clean” code, horrible performance

#187

Post by AnIdiotOnTheNet »

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

If that's true, why does it take forever to load and frequently fail to keep up with my input?

Re: “Clean” code, horrible performance

#188

Post by ysavir »

As a general rule, optimize for your bottlenecks.

If you have a large sum of I/O and can see the latency tracked and which parts of the code are problematic, optimize those parts for execution speed.

If you have frequent code changes with an evolving product, and I/O that doesn't raise concerns, then optimize for code cleanliness.

Never reach for a solution before you understand the problem. Once you understand the problem, you won't have to search for a solution; the solution will be right in front of you.

Don't put too much stock in articles or arguments that stress solutions to imaginary problems. They aren't meant to help you. Appreciate any decent take-aways you can, make the most of them, but when it comes to your own implementations, start by understanding your own problems, and not any rules, blog titles, or dogmas you've previously come across.

Re: “Clean” code, horrible performance

#189

Post by pocket_cheese »

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…

Could you elaborate what you mean by "naive indexes"?

Re: “Clean” code, horrible performance

#190

Post by ajmurmann »

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…

Don't forget the 90% of the processing time that it's waiting for a DB response
Post reply on HN