Re: [Tracker] Roadmap to 0.7

[Jamie McCracken <jamie mccrack googlemail com>]

On Fri, 2009-07-10 at 14:47 +0200, Philip Van Hoof wrote:
> I'm sure that if there are performance issues with Zeitgeist that the
> Zeitgeist team will eventually optimize them out.
>
> For example, indeed, by reimplementing them in a more performing
> programming language, or maybe even by implementing them as miner
> plugins, SPARQL functions or code running in Tracker's processes.
>
> I don't believe that Zeitgeist performing badly will affect Tracker's
> reputation.

putting it in a more performant language wont help as its the
architecture thats suspect

Here is what is zeitgeist is intending to do so far as i see it:


1) Zeitgeist front end <-> dbus <-> Zeitgeist Daemon <-> dbus <->
Tracker

2) Gnome apps <-> dbus <-> Zeitgeist Daemon <-> dbus <-> Tracker


As you can see in that arch, dbus is used twice for everything so you
double the latency and cpu needed to copy and route data. This is
independent of language used although python being the slowest language
around may well exacerbate it further

Here is what im proposing by removing the unnecessary middleware :

1) Zeitgeist front end  <-> dbus <-> Tracker

2) Gnome apps <-> dbus <-> Tracker

bear in mind zeitgeist wants to use tracker for full text searches,
searches for tags as well as updates and its these searches which will
be delayed by their proposed architecture - that is my concern. If there
is stuff that tracker does not or will not do then they can use libs
instead of a daemon to avoid the suspect arch as well

I also feel the real fun in zeitgeist is surely in the front end
zeitgeist timeline based UI they will produce and not back end work
which is best left to us IMO


jamie




>