Hi!
On Fri, Jul 12, 2013 at 6:45 AM, Jonatan Pålsson < jonatan.pals...@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
_______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
