You're (Probably) not a Quant Trading Firm
A few times in my career, I've hit situations where I've been told that I shouldn't use something, or should consider not using something, because it's "slow".
This has included:
- Java 8 Streams when compared to good ol'
forloops - FluentValidations compared to iterative or in-controller validations
- Deserializing dictionaries into typed objects, rather than just accessing properties ad-hoc
- ORMs, such as Hibernate, compared to handwritten queries
...along with a few other things that I'm probably forgetting. I've worked a with a well-tenured software engineer in a tech-lead sort of position that would immediately send back any pull request published with Java 8 streams in it for this reason. I think that pushing back on these tools due to speed (other concerns might be valid) is generally counter-productive [1].
Don't get me wrong, Java 8 streams are slower in some cases, and the same probably goes for most of the other items on the list above. Let's say they're all slower, for the sake of arguing. But here's the thing: It doesn't really matter unless it hurts your customer's experience while using your product.
The latency that these tools introduce are usually at or below the range of tens of milliseconds, not something that most users are going to drop your product for unless speed and efficiency are your differentiators. But they're probably not - you solve a business problem, and whether listing your widgets takes 250ms or 450ms, your customers probably don't care so long as you solve it correctly.
Developers are using these slower alternatives for a reason - they make development easier in exchange for the performance penalty they cost you. It wouldn't make sense to use them if that weren't the case - it's not as though it's just needlessly tossing sleep(1000) into logic.
Software development is oftentimes difficult, expensive, and the primary bottleneck on features being delivered - it's why your customers don't have the features they want. If a case can be made that any of these features can improve productivity even 1%, I'd say it's worth taking a 5ms hit in latency for an API call, or an extra few seconds on startup.
Your customers will thank you, and the developers that work with you will, too.
Ironically, there are usually much bigger fish to fry somewhere nearby in terms of latency and expenses. Message processors trying on messages 10 times for no reason, front-end applications spamming the server with 100 requests unnecessarily, etc. ↩︎