Bug 233583

Created attachment 42560 [details]
Callgrind profile

This bug could probably be related to 202324.

It could also be related to bug 233163... 
- Could you check this on a directory with a lot of files (and hidden dirs disabled) just to check it is not related to the hidden directories ?

Created attachment 42581 [details]
scrolling in directory with ~1000 files

Callgrind output looks different in this case.

Thanks Martin for investigating so much work and providing callgrind outputs. My problem is that I cannot reproduce this issue in my environment, the scrolling is equally fast no matter whether using hidden files or not.

- Judging from the callgrind output you are using the details view. Is this correct? Does the issue also occur in the icons view?

- Regarding comment #4: It is unclear for me whether the scrolling with 1000 files is also slow in your environment. My guess is that it is more related to the number and kind of files, not really to whether they are hidden or not.

- Did you enable previews in your view?

Created attachment 49761 [details]
oprofiles when scrolling in dolphin

Hello Peter,
yes I'm using details view but I haven't enabled any previews in dolphin. I've made some oprofiles while scrolling in dolphin with details and icons view and showing hidden files and without hidden files.

Scrolling is fastest with icons view and no hidden files shown.
Second fastest is details view and also no hidden files.
Scrolling with hidden files shown is really (unusable) slow in both modes.

I guess part of the problem is because I'm using a R600 AGP card with KMS. But that can't explain everything. Unfortunately there doesn't seem to be a single cause for the problem. At least I can't spot a single function which consumes a lot of cpu time. There seem to be a few functions though which are eating up several percent of cpu time.

If you need more info please let me know.

Greetings,
Martin

Created attachment 49809 [details]
ftrace function trace

ftrace log
Options used:
  echo 0 > options/sleep-time
  echo 0 > options/graph-time
Not shure if these options are used for this kind of trace.

Created attachment 49810 [details]
ftraces using funtion_profile_enabled option

The ftraces in the archive are all made with the following options:
  echo 0 > options/graph-time
  echo 0 > options/sleep-time
The ftrace in file "details_show_hidden_graph-time.log" was made with graph-time enabled.

Created attachment 49811 [details]
function_profile ftrace

Forgot to include this file in the previous archive. This is a function_profile trace of dolphin when the mode is set to show hidden files and icons view.

Thanks a lot Martin for all your traces + efforts! I'm currently busy with some other issues, but your traces will help. I've added David Faure to CC, as it also might be kdelibs related and I guess David can spot something suspicious a lot faster than me ;-)

Could it be that this bug is related to 240009?

Yes and no. Yes, apparently, because the callgrind log shows mostly icon loading. But I would say no because, well, we don't load icons for hidden files, as far as I know, so I don't see the relation.

Anyway, this callgrind log shows the issue mentionned in 240009: we were loading icons from KIconEngine::actualSize, which I already fixed for 4.5.0.
http://reviewboard.kde.org/r/4052

So the first step is: please update to kdelibs 4.5 and try again. It should definitely be faster, but unless I'm missing something, it shouldn't fix whatever issue there is with hidden files.

PS: I don't know how to read ftrace logs, never seen these before; they seem too low-level (system calls only, right?) to be useful, anyway.

Hello,
thanks for your replies, I have just tested it with 4.5 and the scrolling is fast when no hidden files are shown and hidden files are shown. So this bug can be closed. Whatever the problem was, it seems to have been solved in 4.5.

A big thanks to all the contributors!

PS: I've created the ftrace logs because it seemed that a lot of time was wasted in some kernel functions which weren't covered by oprofile. Ftrace logs seem to be indeed hard to read. In theory it should be possible to read how long a function takes till it completes. Problem is to find the function which consumes the most CPU cycles because there is no sorting facility implemented in ftrace.