Thread Scheduling

[David Nolden]

Maybe we should first define what an I/O intensive thread is.

For example the C++ duchain threads: For each parsed file, they read
20kb from disk, and then invest a huge effort processing the contents.
That is hardly comparable with a thumbnailing thread, which reads 1MB
and then does a few very cheap scaling operations on the content.

With 2 parsing threads, I can get 100% CPU usage from project parsing
on my home machine, which cleary shows that those threads are _not_
starving. Artificially reducing the number of threads to even less
does not seem very useful. Also, most of the file-system operations
done by the C++ parsing threads are either "stat" operations or
repeated reads of the same source files, and those will be cached by
the file-system and the result delivered instantly.

I think it doesn't make sense to limit the total number of "I/O"
intensive jobs (at least if you count parsing jobs in there), because
parsing jobs are not _that_ I/O intensive.

What might make more sense, if you really think this is a problem,
might be limiting the number of concurrent heavy FS operations, by
adding a global "QByteArray readContents(KUrl file)" function that has
a mutex and makes sure max. X files are read concurrently, or
something like that. However I still don't believe this problem is so
significant that it makes sense to take any measures (we're only
reading tiny files). This might also still kill the performance on
systems like my work-system where the latency is the main problem.
However, you could use this at least to do a profiling whether it
makes a difference.

Greetings, David