Re: [Tracker] Clues regarding improving performance of tracker-store

[Ivan Frade <ivan frade gmail com>]

Hi!

On Fri, Jul 12, 2013 at 6:45 AM, Jonatan Pålsson <jonatan palsson pelagicore com> wrote:

Hi everyone,

I'm interested in a general speedup of indexing in Tracker, and have
therefore been running some performance profiling on tracker-extract,
tracker-miner-fs and tracker-store using OProfile. I found that a lot
of time is spent in the store compared to the other processes (in
rough numbers, it is along the lines of 70% time in store, 15% each
for the extractor and miner) according to OProfile. I was indexing MP3
files when I came up with these numbers.

 Thanks for investigating that.

I'm looking for a discussion of what I can try in order to increase
performance of the store. For me, it seems logical that smaller /
simpler ontologies would yield a performance increase in scenarios
where it is possible to use such ontologies - for instance removing
ontologies related to E-mail when the system running Tracker does not
have E-mail capabilities.

 As Adrien pointed in his email, is not the amount of ontologies but its deepness.

 If you are not using email, that ontology will be translated into some tables in the database but they are never touched. It should not make big difference.

Do you think slimming down the ontologies could yield a performance
boost for the store?

 If you are using Tracker in some specific environment, maybe you could simplify the ontology removing hierarchies and using specific classes for your use cases. Those would be private changes (not to commit in master).

 

Is there support for altering the ontologies? I have seen
.ontology-files. It seems to me that these are the place to go.

The wording of [1] seems to indicate that there are more places in
Tracker where ontologies can be modified other than the .ontology
files. Am I reading this correctly, or are all ontology
related-matters handled through the .ontology files?

 All ontology definitions are in those .ontology files and nowhere else. When Tracker starts, it reads those files, and if they have changed updates the database schema.

 That page lists the changes in the ontology that Tracker can process without losing the user data. Adding a property to the ontology is trivial, but changing a property (range) from list to single-valued is not. What do we do with the previous instances that had multiple values in that property?

 But again, to only way to modify the ontology is editing the .ontology files.

 

 Most of my ideas for improving performance are domain specific (cut Tracker to do exactly what you need). Philip wrote also some ideas to reduce the database file size recently in this mailing list.

 Best Regards,

Ivan