Omg... I am pretty sure that jumps are more efficient than if statements... I did not see him trying this too...
“Clean” code, horrible performance
741–750 of 932 posts
Re: “Clean” code, horrible performance
#742Earlier quoted context omitted.
If you program using design patterns that are 10x slower, your application end up 10x slower, even after you've optimised the hot spots away, and the profiler will not give you any idea that it could be still 10x faster.
no take your tupical web service application. Even if you use design patterns that are 10x slower, your program will still be as fast as your DB and overall system architecture. And the choices on your DB schema, indexes and caches will have 100x more effect on your 99pp response time than design pattern you use.
That's only true if the DB is equally as problematic, and you programming language/framework itself aren't compounding on the overhead caused by the "10x slower" architecture.
On slower languages with slower runtimes, something that is 10x slower than normal code will have much more overhead than in the examples demonstrated by Casey. It won't be about "30ms vs 25ms" as some people are saying. In the past I remember seeing differences between 400ms and 20ms between JBuilder and .to_json in a critical endpoint in a Rails app, to give one example. Sure, one is "cleaner", but in the end it's a 20x overhead that has no place this case.
Also, the myth that "processors spend time waiting for IO" that is spread across this thread is BS. In reality, that's only true for single-user programs. If the app is part of a distributed system, the CPU time can be used to serve more users. This allows you to significantly delay more complex scalability efforts, which is also precious developer (or DevOps) time.
Not to mention that applying "Clean Code" in the first place also takes precious time, which could be used for features or anything making money, even optimizing the DB. Instead, this time is used to mess up the code in ways that have zero proven efficacy, and some developers instead think are terrible.
Re: “Clean” code, horrible performance
#743Earlier 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's not really possible to write hand-coded assembler that's faster anymore.
That is wrong. Just because you didn’t succeed in writing faster code in one case, doesn’t mean it’s impossible. See e.g. [1] on why the Lua vm is written in assembly. It’s from 2011 but not much has changed in the meantime.
Re: “Clean” code, horrible performance
#744Earlier quoted context omitted.
people using clean code ideologies are being prematurely pessimistic and assuming they know much more about a problem than they actually do when they use these clean code techniques. "I don't know how many shapes I've been asked to do, so I'll assume the worst case scenario and make the code slower and harder than the simple naïve solution that would be hard to read(debatable) if we had one million shapes" is a terri…
> people using clean code ideologies are being prematurely pessimistic and assuming they know much more about a problem than they actually do when they use these clean code techniques. No. The techniques are there to let you change your codebase as you learn more about the problem.
there are two ways in which I can understand your message:
a) "these techniques allow for an easy to refactor codebase". I profusely disagree, its easier to refactor a function with some ugly switch than a behavior disseminated over dozens of files.
b) "we are actually careful and not draconian about these techniques only when appropriate", which I don't agree either, as in every experience I had interacting with people that believe in clean code in meatspace, was an obsession with having things done their way, assertions about "code smells" which were literally just not doing whatever they wanted.
maybe there's a c) I'm not seeing. But seeing this thread on its own its already high evidence that these two notions are clearly there in the CC community.
"we are actually performant" becomes "well, actually we are readable" becomes "well, actually we are testable" becomes "well, actually humm... just shut it and write on our code style". Some posts on this thread even talk about people not using these guidelines being evil and having to be ejected. Just imagine how people not suck up on this ideology look at it.
Re: “Clean” code, horrible performance
#745Earlier quoted context omitted.
All of these are instances of doing something _wasteful_, which is the #1 issue he mentions in the list of things that cause performance degradation. Now, your argument seems to be: in the real world, there's so much waste, that virtual function calls pale in comparison. This does not debunk his main point, which seems to me at least the following: all things being equal, writing code with virtual functions that do a…
>all things being equal, writing code with virtual functions that do a tiny amount of work and "hiding implementation details" makes performance worse, sometimes by an order of magnitude but all things are not equal. You can spend a lot of time improving performance of you function calls and get virtually nothing out of it. Because if you optimize something that takes 0.01% of overall execution time, 'order of magnit…
This article is not aimed at people who are working in a codebase where everything is super terrible. It's written for performance aware programming. One of the aspects of performance awareness is awareness of how virtual functions and tiny functions affect performance negatively.
> Also articles like this usually fail to mention code maintenance cost. For example by reducing usage of virtual calls you can make your code unmaintainable/expandable and suddenly every new change will cost you 2x more in development time.
This never actually happens in real life. I've never seen a codebase that is written with "clean code" principles in mind that is also maintainable and easy to develop on top of.
Re: “Clean” code, horrible performance
#746I 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.
Is it? What processes are running on your computer right now, how many are waiting for your interaction?
Further the 0.1% of the time I do interact, I want the results promptly.
Re: “Clean” code, horrible performance
#747Earlier 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…
> He does have a narrow view, but it does not make his claims invalid. I would tend to disagree on this, specially when claims come from the gamedev world. Games are presented as finished pieces (even when they aren't), and not just a release milestone. Ideally, a game is a one-off effort where you write a piece of code and if you're lucky, you won't have to touch it again. So, doing one-off optimizations instead of…
> Two cpu generations later, the Pentium comes out, and both mul and div take 1 clock cycle.
Where are you getting this information? Agner[0] lists DIV as taking 17 cycles at best (8-bit operand already in a register) on the P5, and MUL as taking 11 cycles. Even Tiger Lake takes 6 cycles for DIV.
There are ways [1] to beat that, but I don't think you can get it down to a single cycle.
[0]: https://www.agner.org/optimize/instruction_tables.pdf p.162
[1]: https://lemire.me/blog/2019/02/08/faster-remainders-when-the...
Re: “Clean” code, horrible performance
#748You can optimize even further by creating a custom chip to compute the area of shapes in the order of billions per second. But what's the point? Where is the value? Can't say it better than Knuth: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Clean code has never been about performa…
There's a big difference between "premature optimisation" and thinking about performance.
You shouldn't take that quote to mean you can entirely ignore performance 97% of the time.
Re: “Clean” code, horrible performance
#749Earlier 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…
> He does have a narrow view, but it does not make his claims invalid. I would tend to disagree on this, specially when claims come from the gamedev world. Games are presented as finished pieces (even when they aren't), and not just a release milestone. Ideally, a game is a one-off effort where you write a piece of code and if you're lucky, you won't have to touch it again. So, doing one-off optimizations instead of…
> “Ideally, a game is a one-off effort where you write a piece of code and if you're lucky, you won't have to touch it again.”
Ideally a game pulls in over a billion dollars per year, every year for over a decade. Think World of Warcraft or Fortnite, not Flappy Bird.
Re: “Clean” code, horrible performance
#750I 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…
The gaming industry is not 0.1 percent.