To view parent comment, click here.
To read all comments associated with this story, please click here.
so it makes sense he doesn't trash mono and JIndex too much, even tough they clearly suck in terms of performance and memory usage...
I could never for the life of me understand why the decision was made to use mono as a framework for beagle, something intended to run as a transparent background service. That's not really a slag against mono per se, it's just a question of whether it makes sense to use it for something that should by design be fast and light. In fact Novell compounded this mistake by using mono for zen as well, which led to much of the griping and complaints with SL 10.1 and how slow and freaking unstable the package management was.
Not sure I understand why Sun is making the same mistake with Java either, aside from the obvious. I guess in a way it does provide a benchmark for optimizing the performance of an app like this to accomodate the overhead costs etc. but still...
I've played with Strigi, and I do like the fact that you never "feel" it running. That's how it should be. I don't care if it's spiking my CPU when my system is idle, as long as I get my juice back the moment I need to do something else. The cool thing is that the core engine seems to be pretty much worked through, now it's just further optimizing and building the hooks and plugins. Collaboration with the tracker team on unified interfaces would be fantastic.
well, novell wrote beagle to show how great mono is and promote it, sun wrote their java indexer to show how great java is and promote it. of course, it's not really advertising in my mind, if you see those numbers it's clear there are some problems
yeah, tracker and strigi are the way to go - and as the latter seems to be much faster (30 times?), can index in zipfiles etc, has less dependencies and is working with the Nepomuk project to add contextual information, i'm glad KDE 4 will be using strigi.
I'm not sure you can even compare performance all that usefully since the fixes required to get those extra hits may end up slowing down the app. Still, it was quite impressive for a young project and the developers seem to think the problems were rather minor.
For sure! The report is very useful in showing problems too. The main point that must be addressed the low result count. This is something I was totally unaware of. The reason for that is that I've not come around to writing unit tests to test search reliability. This is the first thing to pay attention to after the KDE metainfo work is finished.
Nevertheless, the overall impression is very good. Most negative points are rather vague and revolve around smaller issues. Please forgive me for being overjoyed at the huge speed differences.
-oever






Member since:
2005-07-07
well, it's written by a sun (Java lovers, duh) guy. so it makes sense he doesn't trash mono and JIndex too much, even tough they clearly suck in terms of performance and memory usage...

if they would make a smart choice, they would go for the best performance and least dependencies - strigi