SQLiteDatabase Plugin for MP2 (3 Viewers)

[MJGraf]

Read Test 4:
Now I enter the first album shown on the screen. This works quite fast - I didn't measure the time, but it was maybe 1sec or so. As a result, I can see 11 tracks of that album - this time WITH covers. Entering this album results in 6 SQL queries:

SQL1 (ProviderResource):

SELECT
  COUNT(
  V.C
) C,
  V.A0
FROM (
  SELECT
  DISTINCT T1.MEDIA_ITEM_ID C,
  T0.TITLE A0
FROM M_PROVIDERRESOURCE T1
  INNER JOIN M_MEDIAITEM T0 ON T0.MEDIA_ITEM_ID = T1.MEDIA_ITEM_ID
  INNER JOIN M_AUDIOITEM T2 ON T2.MEDIA_ITEM_ID = T1.MEDIA_ITEM_ID 
WHERE
  (
  T2.ALBUM = @V0
  AND (
  T1.SYSTEM_ID = @V1
  OR T1.SYSTEM_ID = @V2
)
)
) V
GROUP BY
  V.A0
-------------------------------------------------------
"V0" [String]: '#1'
"V1" [String]: 'ef2d2144-c347-4db2-b7d2-3e634c6f7705'
"V2" [String]: 'f3feaa94-a92c-4ba1-b841-aa617dadefe9'

SQL2 (Artists):

SELECT
  T0.MEDIA_ITEM_ID A0,
  T1.ATTRIBUTE_VALUE A1
FROM NM_ARTISTS T0
  INNER JOIN V_ARTISTS T1 ON T0.ID = T1.ID
  INNER JOIN M_PROVIDERRESOURCE T3 ON T3.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_MEDIAITEM T4 ON T4.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_AUDIOITEM T2 ON T2.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
WHERE
  (
  T2.ALBUM = @V0
  AND (
  T3.SYSTEM_ID = @V1
  OR T3.SYSTEM_ID = @V2
)
)
-------------------------------------------------------
"V0" [String]: '#1'
"V1" [String]: 'ef2d2144-c347-4db2-b7d2-3e634c6f7705'
"V2" [String]: 'f3feaa94-a92c-4ba1-b841-aa617dadefe9'

SQL3 (Genres):

SELECT
  T0.MEDIA_ITEM_ID A0,
  T1.ATTRIBUTE_VALUE A1
FROM NM_GENRES_0 T0
  INNER JOIN V_GENRES_0 T1 ON T0.ID = T1.ID
  INNER JOIN M_PROVIDERRESOURCE T3 ON T3.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_MEDIAITEM T4 ON T4.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_AUDIOITEM T2 ON T2.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
WHERE
  (
  T2.ALBUM = @V0
  AND (
  T3.SYSTEM_ID = @V1
  OR T3.SYSTEM_ID = @V2
)
)
-------------------------------------------------------
"V0" [String]: '#1'
"V1" [String]: 'ef2d2144-c347-4db2-b7d2-3e634c6f7705'
"V2" [String]: 'f3feaa94-a92c-4ba1-b841-aa617dadefe9'

SQL4 (Albumartists):

SELECT
  T0.MEDIA_ITEM_ID A0,
  T1.ATTRIBUTE_VALUE A1
FROM NM_ALBUMARTISTS T0
  INNER JOIN V_ALBUMARTISTS T1 ON T0.ID = T1.ID
  INNER JOIN M_PROVIDERRESOURCE T3 ON T3.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_MEDIAITEM T4 ON T4.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_AUDIOITEM T2 ON T2.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
WHERE
  (
  T2.ALBUM = @V0
  AND (
  T3.SYSTEM_ID = @V1
  OR T3.SYSTEM_ID = @V2
)
)
-------------------------------------------------------
"V0" [String]: '#1'
"V1" [String]: 'ef2d2144-c347-4db2-b7d2-3e634c6f7705'
"V2" [String]: 'f3feaa94-a92c-4ba1-b841-aa617dadefe9'

SQL5 (Composers):

SELECT
  T0.MEDIA_ITEM_ID A0,
  T1.ATTRIBUTE_VALUE A1
FROM NM_COMPOSERS T0
  INNER JOIN V_COMPOSERS T1 ON T0.ID = T1.ID
  INNER JOIN M_PROVIDERRESOURCE T3 ON T3.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_MEDIAITEM T4 ON T4.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_AUDIOITEM T2 ON T2.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
WHERE
  (
  T2.ALBUM = @V0
  AND (
  T3.SYSTEM_ID = @V1
  OR T3.SYSTEM_ID = @V2
)
)
-------------------------------------------------------
"V0" [String]: '#1'
"V1" [String]: 'ef2d2144-c347-4db2-b7d2-3e634c6f7705'
"V2" [String]: 'f3feaa94-a92c-4ba1-b841-aa617dadefe9'

SQL6 (ProviderResource):

SELECT
  T0.MEDIA_ITEM_ID A20,
  T0.MEDIA_ITEM_ID A21,
  T1.MEDIA_ITEM_ID A22,
  T2.MEDIA_ITEM_ID A23,
  T3.MEDIA_ITEM_ID A24,
  T4.MEDIA_ITEM_ID A25,
  T0.SYSTEM_ID A0,
  T0.PATH A1,
  T0.PARENTDIRECTORY A2,
  T1.TITLE A3,
  T1.MIMETYPE A4,
  T1.RECORDINGTIME A5,
  T1.RATING A6,
  T1.COMMENT A7,
  T1.PLAYCOUNT A8,
  T1.LASTPLAYED A9,
  T2.ALBUM A10,
  T2.DURATION_0 A11,
  T2.TRACK A12,
  T2.NUMTRACKS A13,
  T2.ENCODING A14,
  T2.BITRATE A15,
  T2.DISCID A16,
  T2.NUMDISCS A17,
  T3.THUMBNAIL A18,
  T4.THUMBNAIL_0 A19
FROM M_PROVIDERRESOURCE T0
  INNER JOIN M_MEDIAITEM T1 ON T1.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  INNER JOIN M_AUDIOITEM T2 ON T2.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN M_THUMBNAILSMALL T3 ON T3.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID
  LEFT OUTER JOIN M_THUMBNAILLARGE T4 ON T4.MEDIA_ITEM_ID = T0.MEDIA_ITEM_ID 
WHERE
  (
  T2.ALBUM = @V0
  AND (
  T0.SYSTEM_ID = @V1
  OR T0.SYSTEM_ID = @V2
)
)
-------------------------------------------------------
"V0" [String]: '#1'
"V1" [String]: 'ef2d2144-c347-4db2-b7d2-3e634c6f7705'
"V2" [String]: 'f3feaa94-a92c-4ba1-b841-aa617dadefe9'

Test results:
SQL1 (ProviderResource): 4ms
SQL2 (Artists): 1ms
SQL3 (Genres): 2ms
SQL4 (Albumartists): 2ms
SQL5 (Composers): 1ms
SQL6 (ProviderResource): 2ms

Now this finally raised my suspicion that the database - and in particular storing BLOBS such as covers in an SQLite database is definitely not a bottleneck. As you can see, the whole process only takes about 12ms for the database itself INCLUDING loading 11 covers! The covers are loaded in SQL6, which takes in total 2ms. Not really slow....
For the files: The cover(s) of these tracks are identical and have a size of 49KB each - so we are reading those 540KB in about 2ms. Will try to find an album with really high res covers and do this test again...

Michael

 

[MJGraf]

We have a VirtualizingStackPanel, but missing a VirtualizingWrapPanel

Ups, sorry, still not really awake

Does it also take 29 seconds if you use any of the list view modes (small/medium/large)? If so, the network time needs to be looked at. You might try fiddler the shows all traffic and allows measuring the times.

No - that's the point! When I take "large list" for example (i.e. a VirtualizingStackPanel), I can't really measure the time, but I would say it is below 1 second to enter the audio section. So it is clear where the real problem is...

 

[MJGraf]

Finally one more Read Test 4 - but this time in "hardcore". I did everything as described above, but (a) I used "large list" to make MP2 Client more responsive without affecting the database results and (b) I did not enter the first album displayed, but I entered "Innuendo" by Queen. The reason why I chose this album is that the embedded cover art in these tracks is huge. In each flac file (12 in total) there is a cover file with 2,8MB embedded (yes, I like Queen which is the reason why these covers are REALLY high res ). Results are as follows:

SQL1 (ProviderResource): 3ms
SQL2 (Artists): 1ms
SQL3 (Genres): 1ms
SQL4 (Albumartists): 0ms
SQL5 (Composers): 2ms
SQL6 (ProviderResource): 14ms

So what I conclude is the following:

• SQL6 (the one including the covers) takes 7x as long as in the last test when entering an album with 11 tracks each having a cover of 49KB - but 14ms in this context are still negligible.
• On the frontend, entering the album was noticeable slower than in the last test (didn't measure it, but maybe 4 or 5 seconds instead of less than 1sec)
• It seems nevertheless that the database is no bottleneck here - all the SQL queries in total take only 21ms.
• However, I'm starting to wonder whether the time to execute the queries which is shown in SQLDebug.log are really the right figures to measure our database performance - in particular with respect to BLOBS. The reason for my doubts is as follows:
  • we are loading 12 tracks with a cover of 2,8MB each. So we should load 12 x 2,8MB = 33,6MB in total.
  • According to SQLDebug.log this took 14ms.
  • If this was really the case, we had a pure transfer speed of 2,4GB/sec - which simply cannot be true....

I have two possible explanations for this:

• I don't know whether we somehow resize the covers while we import them, so that the covers in the database are actually much smaller than the original ones in the flac files. @morpheus_xx: Can you shed some light on this? Thanks!
• The second possibility would be that executing the SQL query somehow "prepares" the results (which takes 14ms) but it doesn't really transfer them into memory, yet. Reading the covers from disk would then happen afterward when we actually put together our MIA objects using the SQLiteDataReader. This would really be a problem regarding performance tests because in this case we would have to put debug code in form of System.Diagnostic.Stopwatch directly into the code and write the results to the Server.log file. So let's hope it's the first one...

If the first one is true, I would come to the conclusion that putting BLOBS into our database is not a problem at all, because the results above are really reasonable and I doubt whether it would be much faster when we store the pictures in the file system.

Michael

 

[MJGraf]

Seems I can answer my question myself. When I execute SQL6 n Firefox SQLiteManager, it shows for ThumbnailLarge:

BLOB (Size: 2937059)

So this can either be 2,9KB - which would be too small - or 2,9MB which is the original size of my cover...
Houston, we have a problem...

 

[Lehmden]

Hi.

I guess we will have to wait for Lehmden's SQLDebug.Logs

DSL 16000 will be connected here at September 26th so about next weekend I'm able to do lots of testing stuff...

 

[MJGraf]

I'm sitting here in front of my laptop and have to admit that I'm a little bit stuck with how to proceed.
We have first test results, but we don't know whether these results really reflect what we want to measure...
I could imagine to improve the logging in two ways:

• Currently we use a wrapper around the DBCommand to generate our SQLDebug.log. The issue is that this wrapper, when used for reading, returns an IDBReader and it may be possible that the actual reading from disk into RAM happens when the IDBReader is used. When we want to implement further low lever logging, we could hook into SQLiteDatabase.ReadDBValue(Type type, IDataReader reader, int colIndex), which is called every time when we get a single field value from the database. But do we know whether this is really the point in time, when we read from disk? Typically, the IDataReader would be used in a loop like "while (MyDataReader.Read()) { Read the field values... }". So what we usually do is by calling "Read()" we loop through all the rows in our result. Maybe this is the point in time when the data is actually read from disk? We don't really know - but what I know is that we don't have a single point of access to the Read() method. This means that if we want to log how long a call to Read() takes, we would have to implement a wrapper around SQLiteDataReader, which measures the time all the calls to itself take and logs this somewhere. But although the IDBReader interface looks simple, there are a lot of public methods in SQLiteDataReader not contained in the Interface, which we would have to implement. So this is more of a long term task....
• The second idea would be to hook in a little higher in the system - but I don't know where... Of course I could do this in my synthetic tests - just measure how long the call to MediaLibrary.Search(miq, false) takes. But where would be the right hook for queries generated by using the MP2 Client frontend (such as Read Test 3 and Read Test 4)? Is there a single entry point on the MP2 Server Side which is used when the MP2 Client queries for Media Items? I think it should be somewhere in the client communication, but I have no clue about uPnP and don't know where to look at. Can anyone give me a hint? .....

...wait, while I'm writing this, I realize that I'm stupid We could just hook into MediaLibrary.Search - which I suppose is used to perform a search in the MediaLibrary also in case the search is initiated by an MP2 client and which returns a list of MediaItems. So if we measure the time this method call takes, we know exactly how long it takes until we have the desired list of MediaItem objects in RAM - including reading all the values such as the covers. The only disadvantage we have is that this is also not exactly the time our database needs, it includes the time to build our MediaItem objects in RAM, but compared to the actual reading from disk, this should be negligible...

Will try and report back!

 

[MJGraf]

And here is the proof...

What I did is replace this code in MediaLibrary.Search(MediaItemQuery query, bool filterOnlyOnline)

      IList<MediaItem> items = cmiq.QueryList();

with this code

      var sw = System.Diagnostics.Stopwatch.StartNew();
      IList<MediaItem> items = cmiq.QueryList();
      sw.Stop();
      ServiceRegistration.Get<ILogger>().Debug("MediaLibrary: Search time {0} for query {1}", sw.Elapsed, query.ToString());

Restarted the MP2 Server with my 1.7GB test library. Started the MP2 Client on my laptop and entered the audio section ("large list" was still selected). First observation was that this did not result in a log entry. Apparently entering the audio section uses some other MediaLibrary method to query its media items. Then I entered the first album shown (the one with 11 tracks each with an embedded cover of 49KB). And this was in my Server.log:

[2013-09-21 18:15:09,510] [148325 ] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0379708 for query MediaItemQuery: NecessaryRequestedMIATypes: [0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed, 17af940c-66ce-4d23-9d06-bf7f21c04201, 493f2b3b-8025-4db1-80dc-c3cd39683c9f], OptionalRequestedMIATypes: [a61846e9-0910-499d-9868-a1fabce7ccfd, 1fda5774-9ac5-4873-926c-e84e3c36a966], Filter: [AudioItem.Album EQ #1], SortInformation: []

So querying those 11 MediaItems with 11x49KB = 539KB of coverart including reading all the data from the database file into RAM and composing a list of 11 MediaItems took roughly 38ms. Not really bad...

I went back with ESC and now entered the Queen/Innuendo album (remember: 12 tracks with 12x2,8MB=33,6MB coverart). Now I actually measured how long it took until the 12 tracks were displayed on my Laptop: 59 seconds!!! And this was already with "large list" (i.e. VirtualizingStackPanel)! But how much of this was caused by the database? Hold your breath:

[2013-09-21 18:18:27,669] [346483 ] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.2286169 for query MediaItemQuery: NecessaryRequestedMIATypes: [0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed, 17af940c-66ce-4d23-9d06-bf7f21c04201, 493f2b3b-8025-4db1-80dc-c3cd39683c9f], OptionalRequestedMIATypes: [a61846e9-0910-499d-9868-a1fabce7ccfd, 1fda5774-9ac5-4873-926c-e84e3c36a966], Filter: [AudioItem.Album EQ Innuendo], SortInformation: []

Just 228,6ms!!! Again: This is including executing the query itself, transferring all the data from disk into RAM and composing our List of MediaItem objects! If we just calculate the raw transfer speed ignoring the fact that during these 228,6ms we have also executed the query and copied the result a few times in RAM, then we get 1000/228,6*33,6MB=147MB/sec! This result is perfectly reasonable with my Crucial C300 SSD and of course it would be slower with a standard harddisk. But to be honest I doubt we would really be faster if our images were saved as files in the filesystem...

And it gets even better - I left the screen with ESC and again entered Queen/Innuendo on my client and we can see that the SQLiteDatabase's cache works:

[2013-09-21 18:24:13,160] [691975 ] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.1113204 for query MediaItemQuery: NecessaryRequestedMIATypes: [0a296acd-f95b-4a28-90a2-e4fd2a4cc4ed, 17af940c-66ce-4d23-9d06-bf7f21c04201, 493f2b3b-8025-4db1-80dc-c3cd39683c9f], OptionalRequestedMIATypes: [a61846e9-0910-499d-9868-a1fabce7ccfd, 1fda5774-9ac5-4873-926c-e84e3c36a966], Filter: [AudioItem.Album EQ Innuendo], SortInformation: []

Now we're talking about 111,3ms - and a "transfer" speed of about 300MB/sec. I don't think this is real disk (or SSD) transfer speed but the data was already in RAM due to the fact that we executed exactly the same query a minute before, but this is exactly what the SQLite cache is supposed to do...

The remaining question is: If it took 59 seconds to open the queen/innuendo album in the MP2 Client and only 0.2 seconds were caused by the database - what causes the remaining 58.8 seconds?!? Well, in my case I'm sure that most of this is caused by my very slow network connection. While my laptop has 802.11n, my server is usually used as singleseat MP1 Server and client therefore doesn't need a fast network connection and as a result only has 802.11g (i.e. theoretically a maximum of 54MBit/sec, realistically much slower...). So my guess is that transferring those 33,6MB over this lan connection takes most of the 58.8 seconds. Furthermore, my laptop only has quite an old Mobile Intel 4 Series Express graphics chip and if we really load the full 33,6MB image data into the graphics card and let it downscale, this may also take some time...
From my point of view in my personal case (which is only a test case - when I use MP2 in a real case, it is all single seat) there is not much we could improve from an MP2 perspective. Maybe it makes sense to introduce something like a "low res mode" for slow networks / computers in which we downscale image data to a reasonable size before transmitting it to the client. But this is really not first priority...

So my conclusions for now are as follows:

• Storing images in the SQLiteDatabase is not a problem at all - even when the images are nearly 3MB in size (which should be enough for every use case including high res backdrops, etc.). So @morpheus_xx I don't think it would slow down the system if you want to store your FanArt directly in the database. But I think the bigger problem there is that an "Album" is not a MediaItem in our current structure - neither is an "Artist", but this is another story....
  
• From my point of view I can try to tweak the SQLiteDatabase to save some additional ms. But currently I'm not sure if it's worth the effort. There are things that cost much more time and need a speed-up more urgently - such as implementing a VirtualizingWrapPanel or what @Valks is doing regarding virtualization on the database access level. @Lehmden Of course I will have a look at your logs and do some further testing as soon as you are high-speed-DSL-connected and can give me some SQLDebug.Logs. Maybe it is completely different on a regular hard disk instead of an SSD. But until then I think I will not spend more time on this. There are more important things...

And once again: Any comment is welcome
Michael

 

[morpheus_xx]

One question, did you run your tests based on WiP_Alpha3/dev? There was a bug when restoring lists from previous screens which could cause bigger delays that was fixed in this build. If you are up-to-date I really have no idea where the 59 secs come from.
If you can reproduce it, run MP2 trough DotTrace profiler, it will show the time consuming part.

And thanks a lot, nice work!

 

[Lehmden]

Hi.
59 sec really is a lot...Maybe it's due slow network, but I'm using GBit wired LAN and I had issues also.

based on WiP_Alpha3/dev? There was a bug when restoring lists from previous screens which could cause bigger delays that was fixed in this build.

Entering Series from main decreases from about 30 seconds to 3 or 4 seconds with latest Alpha3 build. And the 1 second delay until server is connected also is not reproducible any longer.

With this build the entrance of a series is fast as we first got season view so no need to load 250 media items with thumbs and metadata at once. Only 5 or 10 Season posters are need to be loaded.... And with future VirtualizingWrapPanel this should be speed up any further.

This build brings a lot extra speed for me...

 

[MJGraf]

One question, did you run your tests based on WiP_Alpha3/dev?

ok, seems like I'm behind the current development - my build was based on an old EXP_WIP branch, which currently does no longer exist (probably one of your first Alpha3-test-branches...). Will rebase to current dev and report how this feels like...

I just tested with Titanium skin - very interesting, didn't follow all the developments there. What I can see from my custom logs is that you query for every album the ThumbnailLargeAspect of the first track using LIMIT=1 in the query. To give you an impression how this looks like on the database side, here is a short excerpt of the log:

Spoiler

[2013-09-21 19:26:23,776] [4422590] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0099016 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ '03 Bonnie & Clyde (feat. Beyonce Knowles)], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:23,838] [4422652] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0220414 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ 'Live' Bullet], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:23,931] [4422745] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0238603 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ (The Best of) New Order], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:23,968] [4422782] [28 ] [DEBUG] - MediaLibrary: Search time 00:00:00.2021178 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ #1 Hits 1980-1984], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:24,016] [4422830] [28 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0177425 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ (pronounced 'leh-'nérd 'skin-'nérd)], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:24,051] [4422865] [27 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0110100 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ '74 Jailbreak], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:24,093] [4422907] [28 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0123668 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ 'Round About Midnight], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1
[2013-09-21 19:26:24,112] [4422926] [39 ] [DEBUG] - MediaLibrary: Search time 00:00:00.0128828 for query MediaItemQuery: NecessaryRequestedMIATypes: [493f2b3b-8025-4db1-80dc-c3cd39683c9f, 1fda5774-9ac5-4873-926c-e84e3c36a966], OptionalRequestedMIATypes: [], Filter: [AudioItem.Album EQ 100% Rock, Volume 2], SortInformation: [MediaPortal.Common.MediaManagement.MLQueries.SortInformation] LIMIT 1

That means these queries (including reading into RAM) take between 1ms and 200ms - mostly depending on the size of the embedded coverart. When I understand the code correctly which implements the LIMIT=1 parameter, then we are querying all the tracks, but we are reading only the first one into RAM using the IDataReader.
I have no clue how this works on client side (will have a look into the code tonight). But my feeling is that it may be even faster if we first query without the ThumbnailLargeAspect (LIMIT=1) and then just use the MediaItemID to fetch the ThumbnailLargeAspect of this particular MediaItem. I think I can test this with my synthetic Read Test 1 as I already planned (just taking out the ThumbnailLargeAspect of the OptionalMIAs) and comparing the pure query time (without the read time into RAM) with the one when ThumbnailLargeAspect is included. Don't know if I will have the time this weekend, but I will test it...