691–700 of 932 posts
Earlier quoted context omitted.
How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?
In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".
Earlier quoted context omitted.
> 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 p…
As demonstrated in the example, extensibility costs in performance, and also sometimes in comprehension. If we apply the “clean code” rules as a matter of course, we pay this price always.
In my opinion, we should use interfaces etc at module boundaries only.
I 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…
Earlier quoted context omitted.
100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…
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…
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 magnitude' performance gain is still negligible.
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.
That's why in the real world most of the time you choose clean code and you use optimized nonclean code only on places where you need it. If you look at any lets say web framework internals, you will find a lot of non-clean code, which makes framework faster. But an interface will be done in clean fashion and most of user of the framework will enjoy clean code without need to care about unclean internals.
For all the creeping featuritis that C++ is acquiring like a dirty snowball, doesn't it have a solution for this yet? virtual u32 CornerCount() = 0; you should be able to declare a virtual data member virtual u32 CornerCount; // default value zero how this would be implemented is that it simply goes into the vtable. ptr->CornerCount retrieves the vtable from the object, and CornerCount is found at some offset in that…
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…
This is bad for sustainability
Earlier quoted context omitted.
100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…
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.
Earlier quoted context omitted.
100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…
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.
Earlier quoted context omitted.
All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. So sure, if you absolutely must optimize that 30ms call after you have fixed everything else then go ahead, but very few are at that stage or will ever get to that stage. And if you try to optimize that last 5ms at the expense of the much larger issues then you are actuall…
> All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. Of course it will. If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost. Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with a…
but you are actually talking about optimizing system design, and not reducing virtual functions calls :).
And that the point of this thread: you need to optimize parts that slow you the most.
So no, in most cases optimizing virtual calls won't bring you from 1s to 30ms
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.