Multithreading performance of QtConcurrent Vs QThread with many threads

Short answer: it depends on the nature/logic of the workload.

QtConcurrent runs a pool of threads and it is a higher level API not well-suited to run a large number of blocking operations: if you do a lot of blocking operations you will soon end up draining the pool and having other requests queued. In that case QThread (a lower level construct) is probably better suited for the operation (each one represents a single thread).

I agree with first answer, but I want to add something.

QThread is low-level class which just run OS-specific functions. What is the QtConcurrent? The answer is in Qt source code.

First level: run

QFuture<T> run(T (*functionPointer)())  
{
        return (new StoredFunctorCall0<T, T (*)()>(functionPointer))->start();
}

Second:

struct StoredFunctorCall0: public RunFunctionTask<T>    { ...

Third:

template <typename T>
class RunFunctionTaskBase : public QFutureInterface<T> , public QRunnable
{ ...

Now about QRunnable. When we start QRunnable with QThreadPool we do:

start() which calls tryStart() which calls startThread() which operate with QThreadPoolThread (and it is a QThread subclass) and it is finally call start() of QThread.

And of course this chain is not full, long road, isn't it? So as I know, when we use abstraction, we have abstraction penalty (QtConcurrent has bigger penalty then QThread), but final result is same, it is QThread.