View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007843 | MMW v4 | DB/FileMonitor | public | 2011-05-18 13:48 | 2011-11-09 02:03 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0007843: Performance: loading track list takes 20% longer than MM3 | ||||
| Description | When using a very large DB, MediaMonkey 4 takes significantly longer to load the tracklist than MM3. Tested with //MM/Testing/bigDB/VeryBigDB.rar (on ftp) by switching from Now Playing to Entire Library node (DB was optimized prior to running the test), with column browser disabled. MM3: ~10.2s MM4: ~12.4s Test results are based on a hand timer, averaged 5 times. Note: search performance was fast--the problem seems to be related to loading large numbers of tracks into the view. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1456 | ||||
|
|
My measurements (the same DB, the same process as Rusty): Music node: (MM4 about 20% slower) MM3: 7.2 MM4: 8.6 Location node: (MM4 about the same speed) MM3: 14.4 MM4: 14.2 |
|
|
I've made some improvements and MM4 with filtering (Music collection) took almost same as MM3 without filtering (Entire Library): MM3: 7.8s MM4: 8.0s |
|
|
Fixed in build 1378. Generally speaking we are very close to the limits, there aren't any area where we can get significant improvements. However, in some cases it was possible to improve things: 1. Music node (or any node where sorting by Artist is made) is now improved, because of improved logic in 'the' handling. Now faster by almost 10%. 2. Location node is significantly faster, paths ordering was improved, it should be about 30-60% faster. Note that I haven't compared the release versions and so the improvements are only estimated. |
|
|
Checking in 1381, it's a huge improvement here. It is 2x, 3x, 4x.. faster here. The Location node is nearly instantaneous whereas before it would take over a minute. I only saw a slow loading of the Video > Location > Network where it took 30s the first time it need to show 1 server. Subsequent loading was faster. Filelisting loading seems more responsive as well. I think it might be nice if the status bar would be able to show reading x of y files and have it show the progress bar. On large libraries this will give the user better indication of the loading progress. |
|
|
Lowlander, did you reopen because of Video > Location > Network issue you mentioned? If so, please e-mail me (or upload to FTP) the DB, I'll see whether some improvement is possible there. If you mean 'x of y' showing for tracklist loading - it isn't possible, since we almost never know 'y' before loading the whole tracklist. |
|
|
For both reasons. Wouldn't an SQL COUNT operation be fast enough to first get the total after which the full SQL to get file data is executed? |
|
|
I don't fully understand, do you mean expanding this node? Since the tracklist is empty for the Network node. |
|
|
Yes, I'm just clicking the + sign next to network to expand it. |
|
|
Fixed in build 1383. - We have reverted an older fix, that seemed to optimize, but actually more often cause performance problems like this one. |
|
|
Optimized SQL queries when opening Location subnodes further in build 1384. |
|
|
Re-opening due http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=58472 Can you check if your changes affected something as I tested in 1383 and 1387 and in 1387 it looks that is little bit slower. |
|
|
What exactly you tested? I only optimized SQL queries for expanding Collection -> Location -> Folders which should be faster in most cases, but can be slower for a folders with thousands of subfolders. |
|
|
I only done these steps: 1. D&D tracks from my Desktop Sub-folder onto now playing 2. started to play them 3. right click on one track -> Find More from same -> Folder Library |
|
|
Yes, that's the case. Could you send me your MM.DB? |
|
|
You can used one I have sent on ftp for bug 0006699 as that DB is not converted to 1387 EDIT: To speed things up I thing it should be better to fill track view and than populate tree, due the fact that this way user can work in MM while Tree is focused. |
|
|
Ok, I reverted the SQL changes between 1383 and 1384 as it seems that for most DBs it could be rather a little bit slower. Fixed in build 1389. |
|
|
@Martin try to repro using steps from 0007843:0026061 |
|
|
Fixed in build 1391. - Added significant improvement of Location tree nodes opening. |
|
|
Peke has reported that expansion of Location node is very slow. |
|
|
Fixed in build 1392. - I found out that it happens in case user has a lot media - in Peke's case a lot of CDs. It's _much_ faster now. |
|
|
+ Sped up expansion of 'Album' & 'Artist & Album Artist' nodes |
|
|
Verified 1393 What a refreshment, it is at least 5 times faster. 1391 took 27 Sec, and 1393 less than 5 sec. |
|
|
Tested build 1355 in response to complaint at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=61652, and found that for a very large DB (170k files): Loading tracklist in details view (i.e. waiting for reading files... to disappear so that the tracks can be scrolled) takes: -17 seconds in MM3 -30 seconds in MM4 Note: 'Entire library' was used for both sets of tests. |
|
|
My results: Fast PC: 12s vs 12s (MM3 vs MM4) Slow netbook: 36s vs 38s I.e. pretty much the same results for both versions. |
|
|
My results with 107k tracks in DB (both debug versions). MM3 - 23.5s MM4 - 28.5s Slow laptop (C2D 1.8GHz, 4GB RAM, Win7 pro 32bit). |
|
|
Improved performance in 1456 |
|
|
My results after the fix: Fast PC: 12s vs 6s (MM3 vs MM4) Slow netbook: 36s vs 17s |
|
|
Using Non-Debug versions: MM3 - 17s MM4.1457 - 15.5s MM4.1455 - 19s |
|
|
Verified 1456 (MM4 0000025:0000030% faster than MM3). |
