Annoying counterpoint, of course, I've seen senior developers also stall out on avoiding quadratic code to the point that they didn't get the code delivered and then the project got scrapped.
The most widespread failure I have seen, by far, is to write code that is so abstracted out that it isn't really clear on how to get the necessary parts inline to get at efficient code. You'll have an obvious path on how to load all data for something, but no obvious path on how to get just the relevant points for the algorithm in. This is super hilarious for code paths that try and hide network hits, such that you don't see that that loop is doing a network call per iteration.
> This is super hilarious for code paths that try and hide network hits, such that you don't see that that loop is doing a network call per iteration.
True story: once I worked on a C++ project with a very ambitious junior developer who liked to portray himself as the local authority in performance and code quality. That junior developer once blocked a PR alleging performance problems because a function call was passing strings by value instead of moving them. Except that function call was only called once per run, and its responsibility was to make 1+n calls to a REST service.
Whenever anyone complains about performance, ask for benchmarks. Odds are, even if they are technically right they are still wrong.
> But computational complexity is a separate concern from level of abstraction.
It really depends. Abstractions can and often do to otherwise avoidable copies. It's pointless to argue about computational complexity of an algorithm if you don't even notice that an abstraction you're using is adding a performance penalty in the form of running a linear-time algorithm in the hot path, and is even preventing the runtime from optimizing away problematic code.
I would argue that, in practice, they are not completely separate. Too much abstraction makes it hard to tell what the underlying algorithm is. And even if you can figure that out, makes it hard to optimize.
Echoing my sibling commenters here, I’d love to hear more about this situation. Usually “inlining” and algorithmic complexity are juxtaposed as orthogonal types of optimization, with algorithmic optimization typically even being the reasoning for why the level of abstraction doesn’t matter very much. You typically get a much better speed up from going from O(n^2) to O(n) algorithms than from implementing e.g. Duff’s device, etc
On phone, so will be brief. Will try a longer response later. (Apologies to other responses, not hitting them all.)
Basic point is that many will abstract out data to different locations and ownership lifetimes. So, congrats, you kept us at a lower complexity, but failed to realize you need to first essentially reindex all of the data for that to happen.
Now, I grant that often the problem is more in the data scattered over any number of databases. If there are reasons to keep that spread, though, hard to just sweep it aside.
And then there are those that don't accept, "send it to a solver." Really annoying how often people assume they can easily beat cplex and friends.
I’m curious for more details. I imagine this has to be more interesting than “Just write the double for loop.” “No.” “Ok I guess we’re canceling this project.”
Yeah, it was rarely that silly. Usual thing I'm thinking of are the designs where folks think they can make something like facebook messenger with 200ms latency in the system. You know, "by design." (Of course... I swear that was an interview question I was given once.)
What you wind up with is someone designing a giant system from parts they have read about that, honestly would probably work. However, it would also require retouching pretty much every system in the company to get things aligned. Which, isn't likely to ever happen.
Put a different way, the longer a project spends in design phase, the higher the chance it will not get completed. And all too often people will spend a ton of time in design looking for ways to make sure what they are building will scale to success level loads.
The most widespread failure I have seen, by far, is to write code that is so abstracted out that it isn't really clear on how to get the necessary parts inline to get at efficient code. You'll have an obvious path on how to load all data for something, but no obvious path on how to get just the relevant points for the algorithm in. This is super hilarious for code paths that try and hide network hits, such that you don't see that that loop is doing a network call per iteration.