Re: [Tracker] Performance issue in Tracker 0.7.x due to the sparql to sql translator

Hi Florent

On Fri, Jan 15, 2010 at 12:43 PM, Florent Viard <fviard lacie com> wrote:


We are working on using Tracker and faced some performance issues.
The objective is to retrieve multiple informations about audio files.
So we do a "big" Sparql query on a test base almost 10 000 files

That is the first problem. Retrieve the information of 10.000 files is always a bad idea, in Tracker, SQLite or MS SQL Server. In general, the easy solution of "give me all and i keep it in memory" doesn't work with tracker. You need to retrieve _only_ what you need, and better in an _incremental_ way.

Are you showing 10.000 items in the UI? Maybe you can ask the results in windows of 100 items (check COUNT and LIMIT).
Do you need all those details in the UI? like "sampleRate"? if not, don't ask for them. Every string you select add time to the request.

So, in general: Retrieve only what you need to show in the UI, either in amount of items and in amount of details per-item.

Obviously our SparQL -> SQL translation is not perfect and we will fix that also :) Thanks for the report!

BTW, in maemo we compile sqlite with extra YY STACK DEPTH to allow more complex queries.



First we thought it come from the a limit of the complexity of the Sparql query causing a "parser stack overflow" error that is described here:
But after simplifying the query we discover that the problem may come from the conversion of the Sparql to SQL query in tracker-0.7.14/src/libtracker-data/tracker-sparql-query.vala
It seems that the SQL generated query is not totally efficient and may be improved.

After further investigations, it appears that
tracker-0.7.14/src/libtracker-data/tracker-sparql-query.vala is the source of the problem. There is an issue with the way the SQL query is generated.

Here is the Sparql query that we did:
                "SELECT ?url ?title ?len ?creadate ?artnam ?sbpm ?genre ?bpm ?albtit ?ntrack ?com ?lastaddmod WHERE " //?nbtack
                "{ ?x a nmm:MusicPiece . "
                "optional { ?x nie:isStoredAs ?url } ."
                "optional { ?x nie:title ?title } ."
                "optional { ?x nie:comment ?com } ."
                "optional { ?x nie:contentCreated ?creadate } ."
                "optional { ?x tracker:added ?lastaddmod } ."
                "optional { ?x nfo:genre ?genre } ."
                "optional { ?x nfo:averageBitrate ?sbpm} ."
                "optional { ?x nfo:sampleRate ?bpm } ."
                "optional { ?x nmm:length ?len } ."
                "optional { ?x nmm:performer ?artist . ?artist nmm:artistName ?artnam } ."
                "optional { ?x nmm:musicAlbum ?album . ?album nmm:albumTitle ?albtit } ."
                "optional { ?x nmm:trackNumber ?ntrack } ."
        //       "optional { ?x nmm:albumTrackCount ?nbtrack} ."  //Removed because of the parser limited stack size
                " } LIMIT %d OFFSET %d";

And attached to this mail [ugly-tracker-sql-sparql.txt] is the automatically generated SQL (Reformatted to be human readable).
Trying directly on SQLite this query with the 11k files dataset takes around 2 / 3 minutes to return a result.

In the second attached file [good-tracker-sql.txt] is the same SQL request, simplified by me, that is like tracker is supposed to generate the SQL from the Sparql query.
That query executed with the same 11k files dataset on SQLite, gave a result in only 4 / 5 seconds. (And there, the complexity of the Sparql query could be increased).

I tried to modify myself the source code for this function, but it was too difficult for me because of lack of knowledge on the variables used by the Tracker's internal Sparql parser.

So I think you should modify the code in tracker-sparql-query.vala to generate a query like this by changing the creation of LEFT JOIN by the creation of a SELECT sub-query in the function translate_group_graph_pattern.

I know the common SQL "tips" on Internet that say that LEFT (and RIGHT) JOIN are more efficient than sub-queries. But here, always having ID as an index in all the tables could explain the difference.

A good idea could be to use SELECT sub-queries inside the main SELECT for the optionals of a same subject.


Florent Viard
Software Development Engineer
fviard lacie com

This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited.

tracker-list mailing list
tracker-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]