D4911: add Baloo DBus signals for moved or removed files

[Matthieu Gallien]

mgallien added a comment.


  In https://phabricator.kde.org/D4911#92473, @vhanda wrote:
  
  > I'm not the maintainer of Baloo any more, so I don't want to give it a clear Yes / No.
  >
  > This patch is going to be a big CPU hog. For files this will barely have an impact, but for folders of a large enough size, it's going to result in tons of dbus signals, and more importantly, tons of database lookups and full path constructions. It really will add up. In an earlier version of Baloo, we used to store the full file paths, which meant when a folder moved, every sub-file/folder's URL had to be updated. That was a huge CPU burner. This patch isn't that bad, but it's half way there.
  
  
  For any top folders, only one signal is sent with my patch. Not sure that would add significant CPU overhead.
  If I understand you correctly you fear that fetching the names of the files under the directory will add significant CPU overhead. Do you have any numbers ?
  I believe I could do some benchmarks to see how much CPU is used to get the list of removed paths and not only the Baloo internal ids. What would convince you ?
  I believe one worst case would be somebody deleting a lot of folders selected in dolphin and each one having a very deep hierarchy. Each top folders would mean a DBus signal with a lot of content. Do you think I should benchmarks this worst case scenario ?
  Currently for changed files, one property changes and two signals are sent.
  
  > I cannot see what advantage these signals add, apart from possibly making Baloo more introspect-able. If it's to build applications on top of Baloo, I would recommend against it. The kernel provides file system monitoring APIs which should be used instead.
  
  This is the most important part of the question.
  I think that software like Baloo should provide a way to have live refresh of queries for applications using it. Currently Baloo does not provide this.
  This a real blocker in my opinion for an application. Sure, I could do polling but the user experience would not be ideal at all.
  
  The other alternative is applications using Baloo also watch the file system. That would mean that the user of an application using Baloo would have double quantity of inotify watches. This would also mean that if there is a limit in their number, that would be reached more quickly. Those duplicated watches would exist only to know when the results of the Baloo queries have changed all done by each application using it.
  
  I will probably do that since this way I am independent of any new patches for Baloo and release for me will be easier (no need to bump a dependency, ...).

REPOSITORY
  R293 Baloo

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

To: mgallien, vhanda
Cc: apol, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170305/6aa79f1a/attachment-0001.html>