Thread Scheduling

[Milian Wolff]

David Nolden, 14.12.2010:
> 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.

Thank you,

I think I'll investigate this some more once I have more time. Thought 
currently I agree, it doesn't look important enough (and looks pretty 
complicated) to spent time on.

Maybe later, thanks.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101214/05ec17cb/attachment.sig>