[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: jstreams and strigi for KFileMetaInfo
From: Scott Wheeler <wheeler () kde ! org>
Date: 2006-09-28 0:57:15
Message-ID: 200609280257.16353.wheeler () kde ! org
[Download RAW message or body]
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.
-Scott
--
Many people would sooner die than think; in fact, they do so.
--Bertrand Russell
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic