Re: [Tracker] ANNOUNCE: tracker 0.6.91 released

[Martyn Russell <martyn imendio com>]

Jamie McCracken wrote:
> On Mon, 2009-03-16 at 09:02 +0000, Martyn Russell wrote:
> > Jamie McCracken wrote:
> > > Whilst its not tremendously urgent, the optimal solution AFAICT is to
> > > have an in memory stat table
> > >
> > > Basically calc stats once at startup and then increment/decrement as you
> > > index
> > >
> > > You could recalc stats after removing a volume or hold stats by volume
> > > which would allow you to avoid that
> > >
> > > Anyway I think thats better than say calc stats continuously especially
> > > as applet requests stats every few seconds if you have the stat window
> > > open
> > Eeek, why?
> >
> > We have a signal which updates the stats when they change. Why would we 
> > want to get the stats every few seconds? Makes more sense to just update 
> > the ones that changed and only request the stats once.
>
> well will the signal handle big stat changes like for removable media? 

Yes, we have been testing this over the past few weeks on the Nokia 
device to see how well it works. There is no noticeable speed difference 
that I would write home about.

> ïI would have thought the daemon holding it in memory (EG a hashtable of
> the stats) would make more sense than leaving it to the clients to
> handle it especially if corner cases like above can screw things up

Interestingly :) I just reworked the code to use a hash table for the 
ServiceStatisticsUpdated signal and we only send items and their counts 
which changed. The daemon log should mention this now too.

> the applet is not going to be the only consumer of stats too (EG
> tracker-stats and no doubt some other client will want it too)

Right and currently (and before the SQL statement update) any 
application using GetStats would pause the indexer because it is a user 
request. So every time the daemon sends out the progress, they can 
expect a pause straight after from clients. Using a SQL statement to 
calculate the stats makes very little difference with a 2-5 second pause 
for user requests every time we call GetStats.

--
Regards,
Martyn