[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 307585] Sorting is too cpu intensive for big folders
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2012-09-30 12:04:31
Message-ID: bug-307585-17878-5c3NBp6ZEy () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=307585

--- Comment #6 from Frank Reininghaus <frank78ac@googlemail.com> ---
(In reply to comment #4)
> The insertItems function is only called once.

In that case, my patch won't change anything. My patch targets the case that
"many" items are in the model already, and "many" are added.

> The entire insertItems comes up as one massive resource user. The thing
> you've patched will probably speed it up a little, but the no.1 resource
> user in that function is KFileItemModelSortAlgorithm::sort.

OK, but this doesn't actually say much. If many items are to be sorted, it's
kind of expected that sorting takes some time. The crucial question is how the
time required to sort scales with the number of items. It should ideally be
O(N*log(N)).

> Right now i'm completely rebuilding the way this sorting is done and moving
> it up way earlier in the function calls. I'm targeting
> KFileItemModel::slotNewItems for the sorting since that function is already
> iterating over all the items. So it makes sense to sort there.

I can't see how this could improve anything. The runtime complexity of the sort
operation does not depend at all on the place where the sorting is done.
Moreover, you'd have to consider the possibility that the user changes the sort
order/sort role between the execution of slotNewItems() and inserItems().

> The issue i
> keep having thus far is no natural sorting -_-

This is obviously a no-go ;-)

> Anyway, some steps i will do next:
> 1. Profiling dolphin as it is now with the current sorting stuff and putting
> that profile in here for others to see.
> 2. Test out your patch
> 3. Continue playing with sorting
> 
> i will report back in here once i have targeted profiling data.

I think that profiling data will be much more useful if you obtain them with a
source build. Also Qt should be built from source or at least have debugging
symbols because it seems that much time is spent in unknown Qt functions
according to your log.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]