Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[knuta]

Please pick one specific action you'd like faster (the one that bothers you most), and start a thread with details on how to reproduce the slowness.  Mail a library backup to logs at jriver dot com, so we can test the same on our side.

We might be able to help.

You said "pick one", but there are two I'd like to mention. With my current library the two things I find I'm waiting the most for is:

-Changing the view from video to audio or changing views within the audio section. This is essentially the same action I guess.
-Doing a search within the audio section.

Both these thing take maybe around 2 seconds on my machine. This is by no means worthy of criticism considering the size of the library, which is now at 546 250 files, but Matt wanted me to create this thread so I'm just happy to oblige :-)

In the thread I'm quoting I posted my JRMark score and it was 4364. This is on an Intel i7-3770K sitting on an Asus P8Z77-V PRO with 16GB of DDR3 RAM from Corsair at 1600Mhz. The library, MC and the OS (Win8 8.1) is on a Samsung 840 Evo 500GB SSD. 

I will mail the library backup as requested using the same subject as this thread.

[knuta]

I hope the backup comes through. Ended up at 32.3 MB. Good thing I have a 10Mbit upstream at least :-)

[Matt]

Thanks for the details.  Your library actually feels pretty snappy to me considering the size.  However, we'll use it for performance tuning in the coming months to try to speed some things up.

For example, next build:
Faster: Categories based on file path are faster.

Populating the pane in your Audio > Files view will be about 30% faster.  This is probably around a couple hundred millisecond savings in your case for that view -- not a huge deal, but every little bit helps.

[knuta]

I just have to say that's awesome. Any performance increase is great :-D

I absolutely agree that it is snappy considering the size. I don't know the hardware you test on of course so I don't know how fast it feels at your end, but the fact that everything else I've tried just literally crashes just makes MC that much more impressive.

I'm likely to continue supporting MC for as long as it lives. I've bought 17, 18 and 19 and I wish I knew about it from day 1. Your forum is the only one I've got a bookmark for in the bookmarks bar in Chrome just so I can rush to check the changelog every single update. No other software has got me this excited ever, because it impacts me every single day when I want to access my media.

[Matt]

Another one coming next build:
Faster: Improved performance of core list and tree user interface component (helps  performance of fill, update, etc.).

On your side, you could also help performance by simplifying views (fewer panes, removing list grouping, etc.).

[knuta]

Wow, I'm really grateful for this. Especially considering I'm in the minority, but I guess it will benefit everyone a little bit I would have been very interested in seeing statistics for libraries. I guess most people would consider 10 000 files a big library, but luckily not everyone is as much into this as me :-P

Can't wait to try the next build!

[rjm]

On your side, you could also help performance by simplifying views (fewer panes, removing list grouping, etc.).

Check for playlists in panes. They can really slow things down.

[knuta]

Check for playlists in panes. They can really slow things down.

That is new to me. How does a playlist get into a pane?

[rjm]

That is new to me. How does a playlist get into a pane?

If you edit a pane you will see "Playlist group" as an option.

Using playlists as filters in panes can be very very powerful but I use sparingly for views designed for tag and playlist editing purposes due to performance hit.

[knuta]

If you edit a pane you will see "Playlist group" as an option.

Using playlists as filters in panes can be very very powerful but I use sparingly for views designed for tag and playlist editing purposes due to performance hit.

Ah, I see. I just tried it out for fun. Made a new view with "Imported Playlists", "Artist" and "Album" panes. There are 27676 playlists under "Imported Playlists" because there is a m3u file accompanying a large percentage of the albums I have.
I did not find that it made the view any slower than the others, but that might be down to processing power.

I still find it hugely impressing that the machine can build a list of nearly half a million entries in roughly 2 seconds with 10 or more columns of info.
Imagine writing that list by hand. Would probably take months or maybe even years

[rjm]

I agree, it is amazing.

[Matt]

I noticed your library uses the field 'Folder' heavily, which is the expression FileFolder().

Next build:
Faster: The FileFolder(...) expression is about twice as fast.

However, sorting artist categories by 'Folder' or grouping a file list by 'Folder' is still going to be slower than using a native field (ie. 'Default' sorting for categories and grouping by album, year, etc.).  You might consider changing your views if possible.

[knuta]

Cool, thanks!

I mostly group by folder because the folder name tells me very quickly both which album and which format I'm looking at.
There are some tracks that I have like 10 or more of, from different compilations and what have you :-)

I also have some music in there that is more or less complete discographies of a few labels. I've put the catalog number in front of the folder name to be able to easily sort from oldest to newest release within the label, and when I group by folder I can then easily see the catalog number too.

I just tried removing the grouping and that made a HUGE difference. When I now use a view that is just "File List" without any grouping or panes or anything, the switch from any other view (e.g. Playing Now or any video view) is almost what I would call instantaneous. Maybe I'll try to get by without any grouping at all.

[rjm]

Cool, thanks!

I mostly group by folder because the folder name tells me very quickly both which album and which format I'm looking at.
There are some tracks that I have like 10 or more of, from different compilations and what have you :-)

I also have some music in there that is more or less complete discographies of a few labels. I've put the catalog number in front of the folder name to be able to easily sort from oldest to newest release within the label, and when I group by folder I can then easily see the catalog number too.

I just tried removing the grouping and that made a HUGE difference. When I now use a view that is just "File List" without any grouping or panes or anything, the switch from any other view (e.g. Playing Now or any video view) is almost what I would call instantaneous. Maybe I'll try to get by without any grouping at all.

You should be able to keep what want without a performance hit. Try
1) add pane for Compression (or File Type) to give you format
2) create custom field for catalog number, populate using expression to extra start of folder name, and add new catalog number field to your pane

[jgreen]

I agree.  Any time you use "Folder" you have to wait for Bill Gates to get around to it.  Since you've said you want Album/Artist/Filetype/Etc info, trying using those fields in a view, prioritzed as you wish, and then compare speeds. 

I keep dedicated Panes on top for little-used or Meta- filtering, such as disk, filetype, or whatnot.

[flac.rules]

Nice work, MC is already very fast with large libraries compared to the competition, but more speed handling large libraries is always welcome

[HiFiTubes]

Great stuff...quick question, do the View Schemes affect each other if simply added in a Library? Or are we talking about Parent Schemes/schemes that get used only? Does that make sense? My assumption is it doesn't matter how much you have added, just what fields it's using.

However, I swear when I turned off Video completely speed improved, but it could have been a build change too, not sure. Also, you lose settings and view schemes when you do that so I don't recommend. Right now I have an Audio user that can only see Audio files, but I see same speeds with my Admin user. 387K files and .5 sec switching between schemes. Very fast! Guess it's just MC kicking butt.

[Matt]

Just to underscore rjm's advice:

Expression fields will always be slower than static fields.  An expression must be evaluated for each file.  We've done everything we can to make expressions as fast as possible, but they're simply more complicated and can't leverage data pooling like a static field.

You can fill a static field using an expression (ie. edit and type =FileFolder()).  This puts the expression data into a static format, and the resulting static field will be faster than using the expression.  Only do this if you're trying to squeeze more speed from a huge library -- in a normal library you can use expressions heavily before performance will be an issue.

[Matt]

Great stuff...quick question, do the View Schemes affect each other if simply added in a Library? Or are we talking about Parent Schemes/schemes that get used only? Does that make sense? My assumption is it doesn't matter how much you have added, just what fields it's using.

The number or types of views should not be relevant to performance.

The only thing affecting performance is the current view.  The only border case is that the current view could inherit search rules from its parent view.

[vagskal]

The only thing affecting performance is the current view.  The only border case is that the current view could inherit search rules from its parent view.

Is this true also with split views? I seem to remember a performance hit at least when tagging if I had a split view with two views showing the entire library (with only one view at the time being "current" / active of course). Perhaps you have somehow fixed this.

[Matt]

Is this true also with split views? I seem to remember a performance hit at least when tagging if I had a split view with two views showing the entire library (with only one view at the time being "current" / active of course). Perhaps you have somehow fixed this.

Split views effectively increase the number of current views.  Switching one half of a split to a new view should be the same speed as without a split, but updating when you make tag changes, etc. will get slower as more views are visible at once.

Hidden tabs are an exception to this because any updates they need should be deferred until you actually look at them.

[vagskal]

Thanks for the reply!

I have a split two views view (strange terminology...) where one view is normally hidden and only used when tagging new music. I seem to remember a performance hit when the entire library was "shown" in the hidden view if I did some tagging in the other, visible, view so it is a habit of mine to change the hidden view to show only newly added files, i.e. a small subsection of the library. Maybe this is fixed now so that hidden views do not affect the performance of the visible view.

All performance enhancements are welcome. I am mostly depending on the expression engine being fast. I feel that the caching when switching between a few tabs is better (almost perfect, as in instant) now (except when tagging, and then I would really need it to be fast), i.e. the caching makes the switch between "clean" tabs almost instantaneous but the switch between "dirty" tabs is still  a challenge for the impatient with many expressions to be calculated.

Would it be possible to have the tab switching cache also work when selecting in the left hand tree a ("clean") view that is already open in another tab? It seems that the caching is not working then and that the view is recalculated from scratch.

PS. I have "only" some +150k music files, but a lot of expressions with (almost) no i/o dependent fields/expressions.

[HiFiTubes]

What about AUDIO ONLY filter; commonly used as tons of other file types seem to creep in.

*I just tested it and things are lightning fast actually, with or without it!

[Matt]

PS. I have "only" some +150k music files, but a lot of expressions with (almost) no i/o dependent fields/expressions.

You have the most complicated user library I've ever seen with regards to view and expression complexity.  It keeps me up at night

[vagskal]

Sorry to keep you awake at night. But on the upside that gives you more time to code ; ).

I spent part of the summer updating my web site that I had created and maintained in MS Word. I now used more modern tools and learned (well only the basics) a couple of computer languages used for a WordPress site filled with a lot of unique content laying around, imported using Regex and other tricks. When I now finally got the site to behave the way I want, I find that it has slowed down considerably. Maybe there is a pattern here...  Computer software and hardware just cannot keep up with my creativity. But I feel confident that you will do your best to let me use all the powerful features constantly introduced, at once, on all my music files.

Please delete, if this is too off topic.

[Matt]

@knuta
You might give the latest build a try and see how it compares to when you first mailed the library.  I think the improvements should be noticeable.