View Issue Details

IDProjectCategoryView StatusLast Update
0007843MediaMonkey 4DB/FileMonitorpublic2011-11-09 02:03
Reporterrusty Assigned To 
Status closedResolutionfixed 
Product Version4.0 
Target Version4.0Fixed in Version4.0 
Summary0007843: Performance: loading track list takes 20% longer than MM3
DescriptionWhen 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.
TagsNo tags attached.
Fixed in build1456


related to 0007985 closedjiri Performance: Location node and Find more from same are less responsive than MM3 



2011-05-18 15:02

administrator   ~0025401

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


2011-05-18 16:29

developer   ~0025427

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


2011-05-20 13:30

administrator   ~0025521

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.


2011-05-31 16:53

developer   ~0025800

Last edited: 2011-05-31 19:53

View 2 revisions

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.


2011-05-31 17:07

administrator   ~0025803

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.


2011-05-31 19:53

developer   ~0025815

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?


2011-06-01 09:16

administrator   ~0025826

I don't fully understand, do you mean expanding this node? Since the tracklist is empty for the Network node.


2011-06-01 16:31

developer   ~0025843

Yes, I'm just clicking the + sign next to network to expand it.


2011-06-02 14:00

administrator   ~0025878

Fixed in build 1383.
 - We have reverted an older fix, that seemed to optimize, but actually more often cause performance problems like this one.


2011-06-03 11:38

developer   ~0025895

Optimized SQL queries when opening Location subnodes further in build 1384.


2011-06-11 01:27

developer   ~0026045

Re-opening due

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.


2011-06-11 10:04

developer   ~0026048

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.


2011-06-13 00:03

developer   ~0026061

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


2011-06-13 10:00

developer   ~0026071

Last edited: 2011-06-13 10:01

View 2 revisions

Yes, that's the case. Could you send me your MM.DB?


2011-06-13 11:47

developer   ~0026074

Last edited: 2011-06-13 11:49

View 2 revisions

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.


2011-06-13 12:31

developer   ~0026076

Last edited: 2011-06-13 12:34

View 2 revisions

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.


2011-06-13 21:19

developer   ~0026116

Last edited: 2011-06-13 21:23

View 8 revisions

@Martin try to repro using steps from 0007843:0026061


2011-06-15 09:30

administrator   ~0026143

Fixed in build 1391.
 - Added significant improvement of Location tree nodes opening.


2011-06-16 14:48

administrator   ~0026184

Peke has reported that expansion of Location node is very slow.


2011-06-16 14:49

administrator   ~0026186

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.


2011-06-16 16:58

developer   ~0026196

+ Sped up expansion of 'Album' & 'Artist & Album Artist' nodes


2011-06-21 19:49

developer   ~0026269

Verified 1393

What a refreshment, it is at least 5 times faster. 1391 took 27 Sec, and 1393 less than 5 sec.


2011-11-07 03:00

administrator   ~0028689

Tested build 1355 in response to complaint at:, 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.


2011-11-07 08:55

administrator   ~0028692

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.


2011-11-07 09:12

developer   ~0028693

Last edited: 2011-11-07 09:13

View 2 revisions

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).


2011-11-07 11:22

developer   ~0028695

Improved performance in 1456


2011-11-07 11:25

administrator   ~0028696

My results after the fix:
Fast PC: 12s vs 6s (MM3 vs MM4)
Slow netbook: 36s vs 17s


2011-11-09 01:06

developer   ~0028745

Using Non-Debug versions:
MM3 - 17s
MM4.1457 - 15.5s
MM4.1455 - 19s


2011-11-09 02:02

administrator   ~0028746

Verified 1456 (MM4 0000025:0000030% faster than MM3).