tree 4e9594257a438033787739c41209d3b674457817
parent d7a2a428db781b3fae5df395dccac1bcab867bd5
author Marco Nelissen <marcone@google.com> 1335311699 -0700
committer Marco Nelissen <marcone@google.com> 1335396642 -0700

Further speed up playlist processing

Previously when processing playlists, the entire audio table would be read for
every line in a playlist file. While there would be only one query, a lot of
data was being moved from sqlite to java over and over again, and if the data
didn't all fit in a CursorWindow, additional queries would be done under the
hood.
With this change, playlists are first cached in memory. Then the audio table
is queried, and for every row in the audio table, the best match from the
playlist cache is found. This way the audio table is only traversed once,
so each row is only fetched once. Once the entire audio table has been read,
the in-memory playlist cache contains the best matching entry for each line,
and the playlists are written out to the database. Currently, the audio table
is traversed once for each playlist. This could be further optimized in the
future by processing all playlists at the same time.

b/6346786

Change-Id: Iead3f9ae838d600d085e8e6d3c4874d42314468e