KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Frank Reininghaus]

Hi,

2013/1/9 Mark:
> On Wed, Jan 9, 2013 at 2:51 PM, David Faure wrote:
>> On Wednesday 09 January 2013 11:15:20 Mark wrote:
>>> A little more in depth questions for KDirLister and KFileItem. In my
>>> profiling KFileItem ends up high due to various reasons, but
>>> KDirLister is also a bit of a heavy resource hog due to it's default
>>> behavior of fetching all file information (thus at least 1 stat call
>>> per file) which severely slows down the dir listing process for large
>>> folders.
>>
>> This stat call happens in kio_file though, not in the GUI process where
>> KDirLister lives, right?
>> So I'm surprised that you see that when profiling...
>> or is there a nasty stat() in KDirLister somewhere?
>
> ehm, well i'm not really monitoring stat calls. I'm monitoring the
> time it takes for a directory listing on 1 million files to be
> available in my application.

I agree that we should try to behave well even if there are many
files. However, if it is ensured if all algorithms involved in loading
item information and view setup are O(N) or at most O(N*log(N)) (like
sorting), then the remaining slowness for many files is something that
the user might just have to live with IMHO.

I'm not saying that everything is good as it is. If there are some
operations with quadratic or worse complexity involved, then this
should be looked into, of course. And I also do realise that Dolphin
could benefit from making use of your listJob batching improvements
(https://git.reviewboard.kde.org/r/107520/, very nice work BTW!).

But making extremely intrusive changes to well-tested code which are
only motivated by the (IMHO rather exotic) "1 million files" use case
and which would require large changes everywhere in KDE might not be
such a good idea. Just my opnion, of course.

Best regards,
Frank

P.S.: I agree that the "lazy folder icon loading" issue mentioned
elsewhere in this thread can be disturbing sometimes and could be
improved.