resortAllItems findings

[Frank Reininghaus]

Hi,

2013/7/31 Mark:
>
> Op 31 jul. 2013 11:34 schreef "Frank Reininghaus" <frank78ac at googlemail.com>
> het volgende:
>
>
>>
>> Hi,
>>
>> 2013/7/31 Frank Reininghaus:
>> > Hi,
>> >
>> > 2013/7/31 Mark:
>> >> On Tue, Jul 30, 2013 at 10:12 PM, Mark wrote:
>> >> == Removing the rebuilding of m_items completely ==
>> >> Diff: http://paste.kde.org/p649ae3ea/
>> >
>> > sorry, but this is obviously nonsense.
>>
>> just in case it isn't clear why: your patch destroys the ability to
>> find out which item has moved where during the resorting, which is
>> needed, e.g., to update the selected indexes.
>>
>> Cheers,
>> Frank
>
> Hi Frank,
>
> That explains why I didn't observe any visible regression, I had no items
> selected.
>
> But this still does make it interesting to investigate why the first
> resorting is taking nearly twice as long as the following resort calls.

I had also seen that the first resorting takes a lot longer than the
next ones. Maybe this is because the data needed for the sorting is in
the CPU cache after the first one, such that it can be accessed faster
afterwards.

> Sorry for wasting your time on this :(

Never mind, it's always good to bring forward some new ideas. Even
though not every single one may turn out to be useful, some of them
really do make things better. And also the others might encourage
other people to think about these issues and investigate other ways to
improve the code.

Cheers,
Frank