Linked by Thom Holwerda on Thu 18th Jan 2007 15:11 UTC, submitted by Torsten Rahn
Benchmarks "A number of search engines are available for the Gnome and KDE desktop environments, many based around the open source Lucene search engine. It would be tremendous if we could adopt one of these search engines for the Gnome platform, so we can provide the type of integrated search experience for our users that they really need, irrespective of which distort they are using. So to help in this assessment we have carried out a comparison of four different Unix based indexers [.pdf]."
Thread beginning with comment 203102
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: not perfect but still nice
by meebee on Thu 18th Jan 2007 17:38 UTC in reply to "not perfect but still nice"
Member since:

While I think, strigi is nice and has potential, it proved to be horribly unstable (0.3.11) in my own tests, left around many zombies etc.
It still has a lot of rough edges.
I also can't confirm, that tracker is 40x slower. It is a bit slower, but more in the region of 20% to 30% (*not* times).
Also, what is it good for to be lightning fast when your search results are not good?
Again, strigi seems to be a very young project, so there is hope that these issues are fixed.

Reply Parent Score: 1

superstoned Member since:

well, indeed, all these projects are pretty young, so we'll have to wait to see which one will stand out as the best solution. tracker and strigi of course have (imho) the best chance, being reasonably performant and not depending on controversial stuff like mono/java. if both happen to deliver the same d-bus interface, the best will be used the most, and that's the most optimal solution.

btw strigi also delivers database services and is going to be the foundation of meta-data extraction and manipulation in KDE 4, in addition to having Nepomuk (contextual linking, labeling etc) integration, so i think it has the best cards right now... on the other hand, tracker is close to integration in gnome, and even tough gnome mostly doesn't integrate things very deeply (or at least, does so slowly), gnomes don't like stuff smelling kde'ish. after all, they even rejected aRts, even tough it was plain C, had a gnome-lib dependency and was the only technically reasonable solution by then...

but things can change.

Reply Parent Score: 5

anda_skoa Member since:

they even rejected aRts, even tough it was plain C

aRts is written in C++, not plain C

had a gnome-lib dependency

It didn't unless you you are referring to using glib to some extend, however I think it had a reduced copy if it inside its own source tree.

Reply Parent Score: 2

rayiner Member since:

aRts also sucked.

Reply Parent Score: 3

Jamie Member since:

I also can't confirm, that tracker is 40x slower.

I can confirm its most definitely not!

The article in question tested the ancient 0.5.0 release of tracker which was the first version to include our new indexer framework which was completely unoptimised.

The lastest release, 0.5.3, is tons faster and should be much closer to strigi. We are doing some more optimisation work in the next version so will be interesting to see how they compare then.

Note also strigi does not currently do any string processing like stemming so it lacks the ability to do accurate searches on plurals and stems. This might account for its impressive raw speed as well so we really need to see strigi get features like this to do a more "fair" comparison.

Reply Parent Score: 4

superstoned Member since:

but strigi does create a md5 (or something) hash for every file it indexes, to find duplicates. doe tracker do that?

btw good to hear tracker is getting some performance improvements ;)

Reply Parent Score: 3