D10288: [WIP, RFC] A different approach to reducing KFileItem copies

[Mark Gaiser]

markg created this revision.
markg added a reviewer: dfaure.
Restricted Application added a subscriber: Dolphin.
markg requested review of this revision.

REVISION SUMMARY
  Rationale; KFileItem is being created a _lot_ of times in Dolphin. Usually via a KFileItemList.
  While KFileItem is COW, it is being made in hot code paths (think of updating actions, counting files/folders, etc)
  so having as little of those as possible is a performance win.
  
  For instance, with a "small" folder of just 5000 files i see a KFileItem copy constructer count of nearly 100.000 in callgrind.
  The only actions i did:
  
  1. Open that folder
  2. Split view
  3. Opening an empty folder in one of the views (the empty folder is within the folder of 5000 entries for easy clicking)
  4. Selecting the 5000 items (minus the empty folder)
  5. Dragging the 5000 files to the empty other view
  6. Cancel the action
  
  New functions:
  KFileItemModel::execute - Just takes a lambda with an argument of: "const KFileItemModel::ItemData*". It iterates over all internal m_itemData entries.
  
  KFileItemModel::executeOnIndexes - First argument is a single value container with int as value. Second is the same lambda type as the ::execute function.
  This one iterates over the given indexes and grabs the ItemData object that belongs with it.
  
  For now only DolphinView::statusBarText makes use of it. And all other functions that were calling calculateItemCount.
  
  WIP and RFC part:
  I do realize that i'm now just making internal data available in external functions. That might not be the most neat way, therefore RFC. I would very much like to know of a better way for this.
  An alternative way would be to provide iterator support in KFileItemModel which would give even more flexibility but through a much neater API (and much more complicated to implement).
  Please note that this really is a "optimization for massive folders" you will hardly notice it for smaller ones (say till 10.000 or so).
  It's WIP because this is just a demonstration of how it could be done. This patch reduces KFileItem::KFileItem(KFileItem&) (aka, copy constructor) calls from ~100.000 to ~70.000.
  I expect it can be reduced further to ~20.000 or so (with the above case), but i'm only going to try that if this approach is acceptable.

REPOSITORY
  R318 Dolphin

BRANCH
  kfileitem_reduction

REVISION DETAIL
  https://phabricator.kde.org/D10288

AFFECTED FILES
  CMakeLists.txt
  src/kitemviews/kfileitemmodel.h
  src/views/dolphinview.cpp
  src/views/dolphinview.h

To: markg, dfaure
Cc: #dolphin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180204/8af9bb3a/attachment.htm>