I love by a simple rule: is code being called repeatedly many times a second? Make it performant. Is code called rarely? Make it clean
“Clean” code, horrible performance
711–720 of 932 posts
Re: “Clean” code, horrible performance
#712I agree with Casey.
I think he understands way much more than how to optimize for 60fps as many commentators here point out.
Re: “Clean” code, horrible performance
#713Re: “Clean” code, horrible performance
#714Damn, people are going bananas left and right about this article. I don't think Casey is not targeting general programmer audience where sub millisecond performance does not matter as long as the user experience / business needs are satisfied but this is highly relevant in the world of HFT where you will try to optimise every instruction you execute.
He never mentioned that people should write horrible code for performance but more like pointing out. Personally and professionally, We stay away from virtual functions as long as possible due to unnecessary vTable lookup every time you want to call a method
Re: “Clean” code, horrible performance
#715Earlier quoted context omitted.
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 perfo…
It is. I witnessed it many times on Code Golf substack.
Re: “Clean” code, horrible performance
#716Earlier 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…
Since you bring up React in your example, which framework should one use to build better performing web apps? I know React tends to lack in both dev UX and performance (at least in my exp). Personally I've taken a look at Svelte and Solid, and liked them both. I haven't had the chance to build anything larger than a toy app, though.
We are using Vue instead of React reasons being both performance and simplicity.
Re: “Clean” code, horrible performance
#717Earlier quoted context omitted.
I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, y…
There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it b…
I think it is important to understand what makes a style actually different and what is just semantics.
For instance, if you write a function to do some operation on an object, you could have written that as a method instead. But ultimately it is the same code, it is unlikely that the difference matters much for either performance or readability.
However if you need to do some operation on a bunch of objects you could pack each operation on the individual objects in a method, and call those methods from a main function. Or you could just put it all in one function, with as many nested loops and if statements as there needs to be. Now the difference is real, you pay in performance for a lot of function calls, and following the control flow is different.
Personally I tend to prefer the one function, but sometimes part of it makes sense as its own function, in particular when I can avoid duplication that way.
There is no silver bullet, but best of luck, changing one's style can be hard.
Re: “Clean” code, horrible performance
#718Earlier quoted context omitted.
I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, y…
There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it b…
When I am coding for myself I try to separate the data from the operations performed on it. I also think about how the data flows through the application. I use a mix of procedural and functional paradigms.
Re: “Clean” code, horrible performance
#719I don't like most of these "principles", as anyone can verify by looking at my previous comments, but this article is cherry-picking to its utmost level of unfairness. These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I've never seen anyone seriously try to write computer graphics while "keeping functions small" and "not mixing le…
> you won't be going anywhere in computer graphics by trying to "write pure functions" or "avoiding side effects"
Not sure about this; in my experience (in a different domain, audio processing) you totally can get away with both of these a lot of the time.
Function inclining works well, so you can write small pure functions in a lot of cases (especially if you accept a function that reads from one buffer and writes to another as pure).
As for avoiding side effects, this is normally more about keeping your state updates small and localised (allowing more parts to be pure), which is often not a problem performance-wise.
IME it's much easier to improve the performance of a piece of code which is easy to reason about and change with some level of confidence that your optimisation will not break things.
I know there's some unavoidable global state in computer graphics, but presumably there is lots of code that doesn't directly touch that.
Re: “Clean” code, horrible performance
#720Earlier quoted context omitted.
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 t…
The trouble with this attitude, is that it misses the fact that the _range_ of computing power of devices which ordinary people use is probably greater now than it's ever been.
Let's not even get into low end phones in developing countries or bargain basement android tablets, let's stick with something straightforward - an ordinary PC.
I took a quick look online, sorting by cheapest first I found something with an AMD 3015e in. Based on cpubenchmark.net that gets a benchmark of 2691. Taking a look at the big list of CPUs I see that's equivalent to a powerful desktop CPU from 2008, or a decent laptop from 2012. (The Apple M2 in the current Macbook Air gets a score of 15369, just for comparison.)
So, if you're writing PC software or making a fancy web app and you want everyone to have a good experience with it then you should see how it runs on a terrible new laptop, or a 12 year old good laptop, or a 15 year old powerful desktop.
(And yeah we all have SSDs now which is much better than in the old days, and JS is generally single thread, and single threaded CPU performance has not improved so much - but I think my point still stands.)