[Const-me]

> Concurrency is also not more efficient on a single core.

Concurrency can be more efficient even on a single core. When blocking synchronous I/O is involved, concurrency may help saturate the bandwidth with multiple in-flight requests.

[TickleSteve]

if you are in an I/O bound situation, then yes, concurrency will allow you to exploit some parallelism.

Otherwise, no.

(and in general, people just throw concurrency at the problem instead of analysing whether they are in fact I/O bound or CPU bound).

(Downvoted why??)

[gohrt]

you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%

[TickleSteve]

...and that is true.

When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?

[monix]

People that end up in a position to care about performance are using profilers and bechmarks. This is actually the first rule: don't guess, measure.

Of course it helps when the platform has the proper tools for it. I end up using JMH and YourKit Profiler weekly, because a memory or CPU leak can crash our process and we have pretty strict reliability requirements with a single server processing about 5000 events per second - not extremely demanding, but when it crashes, we can lose money, with the redundancy infrastructure being pretty new.

[sidlls]

This very thing has occupied my day job for at least four months now. It happens when a pre-existing system one has to improve has lots of DB-heavy and compute-heavy operations commingled.

[kod]

Yesterday?