Review Request: Implemented multithreading in KFileItemModelSortAlgorithm

[Frank Reininghaus]

> On Oct. 25, 2012, 12:17 p.m., Frank Reininghaus wrote:
> > Thanks for the new patch! 
> > 
> > I'm afraid it's a lot more complex than it needs to be. A recursive implementation like the one I suggested in
> > https://bugs.kde.org/show_bug.cgi?id=306290#c17 would be much simpler (and not that much different from the 2-thread solution you've posted earlier):
> > 
> > a) No need for your data structure ThreadList.
> > b) No loops.
> > c) No need to add complex code for parallel merging - you'd get that for free.
> > 
> > Maybe the reason for the rather insignificant performance increase is hidden somewhere in this complexity, I can't really say at first sight.
> > 
> > I don't know if you're still motivated to continue working on this, but I would very much prefer a straightforward recursive solution :-) 
> >
> 
> Emmanuel Pescosta wrote:
>     > Maybe the reason for the rather insignificant performance increase is hidden somewhere in this complexity, I can't really say at first sight.
>     It is faster (about 600 ms with 500.000 files) than the 2-thread implementation (The problem was the testing environment => Never run a cpu expensive background process while benchmarking :(
>     
>     > I don't know if you're still motivated to continue working on this, but I would very much prefer a straightforward recursive solution :-) 
>     Yes I am still motivated! :) 
>     
>     I have already done a n-thread recursive implementation (the code is very easy btw) based on my 2-thread implementation -> But this implementation was very very slow .... But I will try to speed it up ;)

I can't really believe that a recursive implementation is slower than the loop-based one you posted here... (provided that you make sure that the number of invocations of QtConcurrent::run() is equal to the number of CPU cores, which means that you always have to do the second recursive sort()-call without QtConcurrent, as I said).

BTW, mentioning only the absolute time saving does not really tell us much. It would be more meaningful to state the relative saving or to say what the absolute sorting times for different implementations (single-threaded, 2 threads, ...) are.


- Frank


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107025/#review20865
-----------------------------------------------------------


On Oct. 25, 2012, 11:48 a.m., Emmanuel Pescosta wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107025/
> -----------------------------------------------------------
> 
> (Updated Oct. 25, 2012, 11:48 a.m.)
> 
> 
> Review request for Dolphin and Frank Reininghaus.
> 
> 
> Description
> -------
> 
> Implemented multithreading in KFileItemModelSortAlgorithm.
> 
> If more than 100 items to sort and ideal thread count is greater than 1 -> sort them with parallelSort (2 Threads)
> 
> Use maximal 2 Threads, because more than 2 Threads are "slower" (more overhead than speed up). (I also have a patch which uses n Threads for sorting, if you want test it ;)
> 
> 
> Diffs
> -----
> 
>   dolphin/src/kitemviews/private/kfileitemmodelsortalgorithm.h 3a596df 
>   dolphin/src/kitemviews/private/kfileitemmodelsortalgorithm.cpp e0aac13 
> 
> Diff: http://git.reviewboard.kde.org/r/107025/diff/
> 
> 
> Testing
> -------
> 
> About 2 seconds faster with sorting 500.000 files.
> About 5 seconds faster with sorting 1.000.000 files.
> 
> 
> Thanks,
> 
> Emmanuel Pescosta
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20121025/9334ce62/attachment.htm>