4 ms·

I spent about a decade doing app performance consulting. The basic three buckets I saw were: 1) Stupid human mistakes. IE: improper configuration, checked in t

I spent about a decade doing app performance consulting. The basic three buckets I saw were: 1) Stupid human mistakes. IE: improper configuration, checked in the wrong file, no testing, etc. 2) Resource constraints, normally because someone was being cheap and thought they could get away with less memory / cpu / network / database / etc than was needed. 3) Architecture. Often the real root cause was that either a system had outgrown its original design, or there really wasn't much of a design in the first place. These were the worst, because they were not easy [fast | cheap] to solve. To the article's point - I don't think I ever saw a single instance of "wrong algorithm" IE: a case where "Big O" was at fault. Did see interesting memory situations, but even those were relatively uncommon compared to "Why are you doing this in js rather than in your db?" or some variation on those other themes.

jbluepolarbear 4y ago
I’ve work in games and simulations for over a decade and it’s almost always algorithm choice that affects performance. A very common issue is storing a bunch of values in a list and constantly searching that list when a dictionary would reduce the Big O and cut down of thousands of value checks that have to be loaded into cache.
torial 4y ago
Over the years, working on performance on .Net applications, I've found among the best ways to improve a .Net application performance is to reduce the GC collection pressure. This is the least obvious way to improve performance for most people because the GC is treated like a magic black box. Recent versions of .Net have made it so straightforward things that used to wreck havoc on memory (like LINQ) no longer do so (yielding good performance gains).
WorldMaker 4y ago
I think both of your points 2 and 3 are heavily impacted by "Big O faults", it's just that you are seeing the practical repercussions from a distance ("postmortem" of the failure so to speak) rather than evaluating the potential problems up front before they occur. "Big O" is a "theoretical" tool for trying to avoid problems up front. When those problems do occur in practice they show up as hitting resource constraints (the algorithms don't scale in resource utilization in a once predicted way, or don't scale with input in ways that align with business needs, etc), or they show up as architectural faults (designs that don't last much beyond initial conditions/testing conditions). In all those cases the "Big O" of the chosen algorithms is never directly "at fault", it's an approximation tool so of course it will rarely be a "smoking gun" in the real world, but it can be a very common hidden "root cause" that's easy to overlook in problem "post mortems", often: Had the developer at the time a thing was written been better aware of the "Big O" complexity of their chosen algorithms they might have found potentially better trade-offs for resource utilization given resource constraints or for architecture given expected long term design. I know that's a lens I apply a lot when doing performance work and trying to find "true" root causes, thought exercises along the lines of: What was the intended "Big O" of this algorithm when originally written? What in practice violates that intention? Where are hidden "Big O" costs that a developer might have missed because it seemed ancillary to their core algorithm they were working? (In .NET, for a concrete example of applying "Big O" to performance fixing, I can go to some length on "ToList Considered Harmful" and how it's a common accidental O(n)/O(n^2)/O(n^m) sink, in both time and especially space [memory usage], that is non-obvious because it is so easy to write .ToList() everywhere and so common in many codebases/code-styles to find it mindlessly everywhere and a lot of APIs wastefully use IList<T> or ICollection<T> rather than IEnumerable<T> or IQueryable<T> as their API boundary and a lot of developers use "ToList Debugging" as a crutch and yet ToList doesn't look like it intentionally means to be a part of the algorithmic complexity of the actual business logic it interferes with.)

jbluepolarbear 4y ago

I’ve work in games and simulations for over a decade and it’s almost always algorithm choice that affects performance. A very common issue is storing a bunch of values in a list and constantly searching that list when a dictionary would reduce the Big O and cut down of thousands of value checks that have to be loaded into cache.

torial 4y ago

Over the years, working on performance on .Net applications, I've found among the best ways to improve a .Net application performance is to reduce the GC collection pressure. This is the least obvious way to improve performance for most people because the GC is treated like a magic black box. Recent versions of .Net have made it so straightforward things that used to wreck havoc on memory (like LINQ) no longer do so (yielding good performance gains).

WorldMaker 4y ago

I think both of your points 2 and 3 are heavily impacted by "Big O faults", it's just that you are seeing the practical repercussions from a distance ("postmortem" of the failure so to speak) rather than evaluating the potential problems up front before they occur. "Big O" is a "theoretical" tool for trying to avoid problems up front. When those problems do occur in practice they show up as hitting resource constraints (the algorithms don't scale in resource utilization in a once predicted way, or don't scale with input in ways that align with business needs, etc), or they show up as architectural faults (designs that don't last much beyond initial conditions/testing conditions). In all those cases the "Big O" of the chosen algorithms is never directly "at fault", it's an approximation tool so of course it will rarely be a "smoking gun" in the real world, but it can be a very common hidden "root cause" that's easy to overlook in problem "post mortems", often: Had the developer at the time a thing was written been better aware of the "Big O" complexity of their chosen algorithms they might have found potentially better trade-offs for resource utilization given resource constraints or for architecture given expected long term design. I know that's a lens I apply a lot when doing performance work and trying to find "true" root causes, thought exercises along the lines of: What was the intended "Big O" of this algorithm when originally written? What in practice violates that intention? Where are hidden "Big O" costs that a developer might have missed because it seemed ancillary to their core algorithm they were working? (In .NET, for a concrete example of applying "Big O" to performance fixing, I can go to some length on "ToList Considered Harmful" and how it's a common accidental O(n)/O(n^2)/O(n^m) sink, in both time and especially space [memory usage], that is non-obvious because it is so easy to write .ToList() everywhere and so common in many codebases/code-styles to find it mindlessly everywhere and a lot of APIs wastefully use IList<T> or ICollection<T> rather than IEnumerable<T> or IQueryable<T> as their API boundary and a lot of developers use "ToList Debugging" as a crutch and yet ToList doesn't look like it intentionally means to be a part of the algorithmic complexity of the actual business logic it interferes with.)