> But this isn’t “critical software”, either I strongly disagree. Anyone on the project would have (hopefully) known what it was being used for and how critica

> But this isn’t “critical software”, either I strongly disagree. Anyone on the project would have (hopefully) known what it was being used for and how critical timing is for that task. Heck, the entire reason the project exists is to expedite the task. That translates directly to minimum-latency being a project constraint, so this to me just sounds like a project that failed to meet its constraints. If you're an application developer, you're generally going to have a clear idea of what the priorities are for your project and what does and doesn't matter (in terms of performance and otherwise). Maybe there's a case here for systems/library programmers erring on the side of performance because they genuinely don't know who will be using their code for what. But even then- if a library isn't fast enough (put differently: if the library's priorities diverge from the application's priorities), the application developer should know that and not use that library for their application. This trend of universalist performance-puritanism is exhausting. Performance is one of many priorities that a project may have. Know your target user, set your priorities accordingly, and develop your code in line with those priorities. No single priority gets to be so important across an entire field that everything else takes a back-seat.