2 ms·
> they could still be several orders of magnitude away from optimal I have a fair bit of experience in optimisation and this is ridiculously... optimistic, sha
by _a_a_a_ 3y ago
> they could still be several orders of magnitude away from optimal
I have a fair bit of experience in optimisation and this is ridiculously... optimistic, shall we say. The only way you can get literally orders of magnitude speed up is if some pillock put literally orders of magnitude of slowdown in originally, typically by combining a couple of O(n^2) operations, and even then only seen that a few times and it's easy to fix.
- fl0ki 3y agoI've seen far worse crimes than that :) Example: Writing what is effectively a graph algorithm where every edge/node lookup is a string key in a hash map. Transforming the string keys into dense integer offsets once-off costs nearly nothing, and reduces every single lookup into a direct memory offset. That one optimization alone was an over 30x speedup, and you can imagine that if they wrote it like this then there was a lot of other low hanging fruit. These people passed one of the most famous computer science hiring bars in the industry, and this code passed review. When I interview people with a puzzle version of a problem like this, 95% of candidates still use string keys instead of reducing them to integers, so this is shockingly common and not at all an edge case. It's just one of dozens of common performance antipatterns I see in code written by people with TC over $500k USD. It's also why I call bullshit when people online claim that computer science interviewing is gatekeeping and they don't need algorithms in their day job. This is false both ways; it's not gatekeeping successfully enough because nonsense like this makes it to global production and costs tens of millions, and anyone who wants to succeed in this job is expected to know better.