jstreams and strigi for KFileMetaInfo
wheeler at kde.org
Thu Sep 28 01:57:15 BST 2006
On Wednesday 27 September 2006 14:54, Carsten Pfeiffer wrote:
> so all the KFileMetaInfo plugins need to be to ported xmlindexer, then? I
> suppose it offers a similar API?
> Then strigi indexing might indeed become faster. However, KFMI would become
> slower for everyone not using strigi. E.g. most of the laptops have slow
> IDE drives where I wouldn't want to have an indexer running. I do use
> slocate/updatedb, but I hate it when it's running, because I basically
> cannot do anything else because of the I/O.
Everyone really, really hopes that systems won't be as stupid by the time that
KDE 4 comes around. Reliable file-change notifications are an absolute
necessity for modern OSes.
> So if we want to optimize strigi, we should have a look at what's actually
> slow in KFMI and perhaps offer a lower level API that xmlindexer could use.
> I'm not convinced yet that KFMI using strigi as a backend is faster
> (contacting the strigi daemon, checking if the file is indexed, checking if
> the index is up to date, possibly indexing it, then sending the metadata
> back to the KFMI (as XML?) and converting it into KFMI datastructures).
I can't speak for Strigi, but certainly meta-data-caching is faster than
not-meta-data-caching, which seems to be half of the debate here.
KFMI itself is a bit rough around the edges performance wise, but it's been
ages since I properly profiled it (plugin loading used to kill it). It seems
that right now for instance, with audio data, it adds about 300% overhead
relative to using TagLib directly.
But the real thing is that's CPU time, not wall-clock time, and almost always
with indexing the real performance killer is IO. On a cold read of 500 files
it's the difference between 20.8 and 20.2 seconds on my machine. ;-)
If things are set up so that there's a system for hooking in a metadata
cacher, whether Strigi or otherwise that's probably a good thing. On the
other hand I'm not sure that ditching KFMI in the same swoop is a good idea.
Many people would sooner die than think; in fact, they do so.
More information about the kde-core-devel