If you are solving business problems with your product, I would say in most cases yeah.
I interviewed a few years back for a company that was claiming to run benchmark tests on one of their telecom products written in golang, claiming it made their clients happy. Then afterwards they said that they usually have incidents and you need to carry the work laptop with you, I guess it’s all about setting the right priorities and raw performance is never in the top ones for such products. I obviously declined that offer after hearing that, as that is a simple example of a dysfunctional product.
It’s all about understanding and measuring correctly the performance of parts of your system. The easiest way these days is to send telemetry from the parts of the application that interests you. The tricky thing is that there is no rule of thumb on how to do it optimally, so depending on how you implement it, that will determine the quality of insights you will get.
I want to enforce the same point as @dimitarvp above. If your processing is already as concurrent as it can be, trying to optimize single-threaded raw speed is a fool’s errand in most cases.
If that is critical for the product, then the most optimal way is to offload it to a low-level language like c/rust/golang, otherwise you might get into the situation where you have a horrible codebase that nobody can understand and maintain, while providing some mediocre optimizations.
