Print

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

[laerm]

Hi all -

I upgraded to MC15 a few days ago after I saw it has a way to put music onto iPhones (none of the other new features I figured I'd get a lot of use out of). I must say, 15 seems much slower than 14. Now, I know my computer is old, but 14 wasn't like this. Going between library tabs will take 10 seconds or so for the screen to refresh and MC locks up in this time. Same goes for clicking on a different genre or from going from one artist selected to displaying the whole library. Sometimes MC will even lock up and crash here.

Once again, I have an older computer and a large (~65000 file) library living on a NAS (wired, not wireless), but I wouldn't expect going from 14 to 15 to cause such a drastic slowdown in my machine. I've attached the benchmark as well as system info so you can see.

Does anyone have any tips how I can speed up? Interestingly, Theatre view (which I use 3/4 of the time) only seems a fraction slower, if at all. Also I know that MC14 often took 250+ MB of memory, while I have yet to see MC15 go over 100MB. It's great it's more efficient, but, perhaps in my case, I haven't really gained anything.

Thanks very much...
Micah

Code: [Select]

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 15.471 seconds
    Single-threaded floating point math... 7.256 seconds
    Multi-threaded integer math... 30.886 seconds
    Multi-threaded mixed math... 14.467 seconds
Score: 279

Running 'Image' benchmark...
    Image creation / destruction... 3.791 seconds
    Flood filling... 8.351 seconds
    Direct copying... 7.435 seconds
    Small renders... 11.140 seconds
    Bilinear rendering... 15.879 seconds
    Bicubic rendering... 20.335 seconds
Score: 329

Running 'Database' benchmark...
    Create database... 2.011 seconds
    Populate database... 6.424 seconds
    Save database... 0.427 seconds
    Reload database... 0.153 seconds
    Search database... 8.232 seconds
    Sort database... 8.976 seconds
    Group database... 8.804 seconds
Score: 614

JRMark (version 15.0.46): 407

Code: [Select]

Media Center 15.0.46 C:\Program Files\J River\Media Center 15\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Pentium 4 2372 MHz MMX / Memory: Total - 1048 MB, Free - 471 MB

Internet Explorer: 6.0.2900.2180 / ComCtl32.dll: 5.82.2900 / Shlwapi.dll: 6.0.2900 / Shell32.dll: 6.0.2900 / wnaspi32.dll: 4.60 (1021) , ASPI for Win32 (95/NT) DLL, Copyright ﾩ 1989-1999 Adaptec, Inc. / Aspi32.sys: 4.60 (1021)

Ripping /   Drive D:   Mode:Normal  Type:Auto  Speed:Max
  Drive G:   Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Get cover art: Yes /  Calc replay gain: Yes /  Copy volume: 100
  Eject after ripping: Yes /  Play sound after ripping: No 

Burning /  Drive D: YAMAHA   CRW-F1E            Addr: 1:0:0  Speed:44  MaxSpeed:44  BurnProof:Yes
  Drive G: _NEC     DVD_RW ND-3500AG   Addr: 2:0:0  Speed:32  MaxSpeed:32  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /

Portable Device Info
  Removed devices:


Interface Plugins:
  last.fm (Active)
  TiVo Server (Active)

[JimH]

During import, MC will be slow.  Thumbnailing can also slow it down.  Cover art lookup.

Leave it running for a while.

[laerm]

During import, MC will be slow.  Thumbnailing can also slow it down.  Cover art lookup.

I'm pretty sure none of that is running... I disabled all background processes, and I imported my library from MC14, so all of that should already be taken care of...right?

Micah

[Alex B]

It needs to build the thumbnails anyway. "Thumbnails" are small and fast cached copies of cover art, image files and screenshots of video files.

I don't know if thumbnailing has anything to do with your issue, but you can force MC to prebuild all thumbnails in Options > Tree & View > Thumbnails > Build missing thumbnails...

[laerm]

Hmmm...well, all I use this machine for is MC, and it's been running for at least a day. I would hope it had finished all of its background tasks at this point.

Going on my benchmark report, is my machine too slow for this?

Thanks -
Micah

[Matt]

Our goal is for each version of Media Center to be faster than the last, and as such, I would expect Media Center 15 to be faster than Media Center 14.

Is is possible there's just a certain view that's slow because of a complicated user-created filter, or that the NAS with the library is performing poorly?

You could try a local library on your C:\ drive as a test.

It might be helpful to use Help > Logging and see if it shows any abnormal activity.

Thanks.

[zxsix]

I would suggest initiating the thumbnail building utility overnight and leave it alone until it's done.  Do your speed testing after that's done.  Also if you nas has an option for opportunistic locking, disable it.  Also test with the default panes viewscheme on both versions.  I'm not sure how MC handles their indexing of the database, but as a DBA I can tell you that 2 reports, or viewschemes in the MC realm, that sort on 2 different fields may take much different times to run...assuming field A is indexed and field B is not.

[kurushi]

Our goal is for each version of Media Center to be faster than the last, and as such, I would expect Media Center 15 to be faster than Media Center 14.

Thanks.

Just For curiosity when you add some new functions MC don't need more ressources?
I remember the first time i have seen the theater view i was very surprised of the little ressources it needed for to be run!

[Matt]

Just For curiosity when you add some new functions MC don't need more ressources?

Executables and DLLs are loaded into memory when used*.  So adding new functions can create bigger executables that take more memory to load.  (*it's actually a little more complicated than that because they're 'memory mapped' meaning the memory is allocated, but only filled from disk as needed).

This "code size" memory usage is only a small part of a program's total memory usage.  Memory usage for things like buffers of images, database information, etc. account for a bigger portion of memory usage.  Code size memory usage is also mitigated by breaking components into DLLs and only loading the DLL if it's needed.

However, memory usage is just one facet of 'resources'.  CPU usage is probably the most important resource, and code that isn't running requires no CPU.  This is why adding Theater View didn't change the performance of Standard View.

To give an example, let's say for v16 we add the huge new feature of EasyBake oven support.  The main program executable might grow by 500KB (500KB is a lot of code).  That means running the program would require 500KB more memory.  However, let's say we also made the the core database search routine 10% faster.  In day-to-day usage, the program will seem faster.  Is it consuming more resources?  I guess it just depends on how you look at it.

[Alexx]

To give an example, let's say for v16 we add the huge new feature of EasyBake oven support.  

LOL!

[laerm]

Our goal is for each version of Media Center to be faster than the last, and as such, I would expect Media Center 15 to be faster than Media Center 14.

Of course, that has been my experience so far.

Is is possible there's just a certain view that's slow because of a complicated user-created filter, or that the NAS with the library is performing poorly?

You could try a local library on your C:\ drive as a test.

Nope, nothing complex going on at all. Only filter is for audio file types. Can't say about the NAS -- it seems to run fine when I use it as an iTunes server to my Macbook.

It might be helpful to use Help > Logging and see if it shows any abnormal activity.

OK, will do. Um, what counts as abnormal activity?

Thanks!
Micah

[laerm]

I would suggest initiating the thumbnail building utility overnight and leave it alone until it's done.  Do your speed testing after that's done.

OK, I will give this a shot tonight and report back tomorrow. Thanks.

Micah

[kurushi]

Thanks Matt for this really good & simple answer!

[Lasse_Lus]

how does your view filter look like ?

don't use path contain in the filter, also don't use category Filepath...both will slow down

also remember that a search will not inherit your filter search but rather search the hole database and then apply the filter

and if you use path in a view it's very important that "media type=audio" comes first in the query, (if you query for audio that is)

you can also try to empty the cache folder sometimes

..and of course expressions in the pane is a really slowstopper for not cpu heavy machines

[bunglemebaby]

don't use path contain in the filter, also don't use category Filepath...both will slow down
and if you use path in a view it's very important that "media type=audio" comes first in the query, (if you query for audio that is)

Can you expand upon this a bit more? Or point us to someplace that does? I use filepath to exclude my "import directory" from the rest of my library. Are excluding and including directories equally slow?

also remember that a search will not inherit your filter search but rather search the hole database and then apply the filter

I'm a little unclear on what you mean by this.

you can also try to empty the cache folder sometimes

Is this a manual action done via Windows Explorer or done via the MC UI?

..and of course expressions in the pane is a really slowstopper for not cpu heavy machines

I assume that the expressions in panes only slows things down when one of the expressions is selected in the pane?

MC has definitely slowed down for me over time and I have no doubt that it's mostly (or all) due to the way I've set up my views etc, so tips like these are a huge help.
-JB

[Lasse_Lus]

bunglemebaby, i'm not sure i can expand, the best thing to do do is to clock the answers, create smartlists with different queries, but same results (use a stopwatch to see the difference)...i stopped using path contain when i noticed the view could be grabbed 4-5 seconds faster..when its "tagged" lets say by a special keyword..

regarding inherit...(i wrote a post on that 8 weeks ago,) it's so important regarding speed what is on top of the query..so [Media type]=Audio AND [Bios]="monkey" will be 15 times faster then [Bios]="monkey" and [Media type]=Audio...so when you do search in a view that is already filterd out, it will search for monkey in the hole database and then apply [Media type]=Audio.

the cache, i'm not really sure about that, but sometimes the cachefolder is really large, i wipe it out from time to time..

regarding expressions, i meant as you noticed, when you selecting a expression in the pane

the bottomline is that if you don't have a fast computer, i have MC benchmark around 800 you have to check your queries...i guess you don't notice the slowdown when sitting on a 2500 benchmark PC..
but my prime views only use a keyword and i get the result below 0.5 second with 250'k files and i'm really pleased with that 

[laerm]

I would suggest initiating the thumbnail building utility overnight and leave it alone until it's done.  Do your speed testing after that's done.

OK, I did this last night and it does seem to be faster today, even if the benchmark doesn't really reflect it:

Code: [Select]

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 15.458 seconds
    Single-threaded floating point math... 7.247 seconds
    Multi-threaded integer math... 30.914 seconds
    Multi-threaded mixed math... 14.488 seconds
Score: 279

Running 'Image' benchmark...
    Image creation / destruction... 4.249 seconds
    Flood filling... 9.647 seconds
    Direct copying... 7.844 seconds
    Small renders... 11.044 seconds
    Bilinear rendering... 15.975 seconds
    Bicubic rendering... 20.420 seconds
Score: 318

Running 'Database' benchmark...
    Create database... 1.938 seconds
    Populate database... 6.986 seconds
    Save database... 0.419 seconds
    Reload database... 0.153 seconds
    Search database... 7.997 seconds
    Sort database... 8.974 seconds
    Group database... 9.087 seconds
Score: 605

JRMark (version 15.0.46): 401
It, uh, looks to be a few points slower on the DB end.  ?

Also if you nas has an option for opportunistic locking, disable it.

Nope, sorry.

So I guess things are OK for now, but I will get back on this thread if it goes haywire again. Thanks everyone for their help!

Micah

[bunglemebaby]

regarding inherit...(i wrote a post on that 8 weeks ago,) it's so important regarding speed what is on top of the query..so [Media type]=Audio AND [Bios]="monkey" will be 15 times faster then [Bios]="monkey" and [Media type]=Audio...so when you do search in a view that is already filterd out, it will search for monkey in the hole database and then apply [Media type]=Audio.

This part still has me confused. I understand what you mean about the order of the search being important. What loses me though, is how MC applies the search order. I tried reading up some in your other thread about this and from what I can tell MC seems to use the reverse search hierarchy from what would be appropriate (when inheriting from parent schemes)?? My main audio views are buried 4 levels deep in view categories with at least one search/filter at each level. In my testing it looks like this only adds about half a second to the search, but the approach still seems counter-intuitive.

but my prime views only use a keyword and i get the result below 0.5 second with 250'k files and i'm really pleased with that 

This has me wondering if I wouldn't be better off using one or two complicated custom calculated fields and then just using these fields to filter my view schemes. I'm running on a machine with a similar MC score as yours and some of my view schemes take closer to 3 seconds to load with ~1/4 the library size. I'll post back if that has any quantifiable success.

the bottomline is that if you don't have a fast computer, i have MC benchmark around 800 you have to check your queries...i guess you don't notice the slowdown when sitting on a 2500 benchmark PC..

Agreed, I scored a 750 with my machine and normal operating conditions (FF & Outlook open), and it's amazing the difference some of these things can make to the speed of MC once you start to dig into them.

Thanks again for the tips,
JB

[Lasse_Lus]

bunglemebaby, i use confishy's autotagger...then you can set "advanced rules" including path's and so on ending up with one "searchtag" (or what to call it) that you can use in the filter...it's also easier to administrate the views if they become less crowded.

regarding the inherit. custom search speed (in the upper right corner) depends on which fields has default search field ticked (in option/manage library fields) so there can be quite a difference between databases and i myself have tons of custom fields..so if was in the "appropriate order" i could have most of them ticked, now i can't...i also have a lot of text large value fields...and maybe not everyone has that...but as it is now every search goes into those large textfields even though the parent exclude those files, meaning i have to search the text/largefields separately.

[Matt]

so if was in the "appropriate order" i could have most of them ticked, now i can't...i also have a lot of text large value fields...and maybe not everyone has that...but as it is now every search goes into those large textfields even though the parent exclude those files, meaning i have to search the text/largefields separately.

You've reported this before and I only maybe understand.

Would you be willing to make it slow, make a library backup, then email me a copy with instructions on how to see the slowness?  I'm matt at jriver dot com.

Thanks for any help.

[Lasse_Lus]

sent..

[Matt]

sent..

Thanks for the library.  We need some time to look at the speed issue.

One thing that jumped out immediately about your library is that you have 10 fields:
Text
Text01
Text02
...
Text10

They take the lion's share of the space in your library.  They're populated with exactly the same data.  Duplicating big strings across multiple fields is not efficient (duplicating strings inside a field is efficient), and I can't think why you would do this.

Is this just to demonstrate / exaggerate the slowness?

[Lasse_Lus]

Is this just to demonstrate / exaggerate the slowness?

thats' correct sort of dummies 

i wrote

...created text fields to compensate...

[Matt]

Coming in build 57:

Optimized: Search engine uses more sophisticated logic for deciding the order to evaluate pieces of a database query, providing substantial speed improvements in some cases.
Optimized: Database search engine can better discard duplicate search terms, helping performance in applicable cases. (stacking of similar searches is common in nested views, etc.)

Thanks a lot for all the help.

[Lasse_Lus]

amazing, 10 times faster   

[HiFiTubes]

I noticed an increase in speed but on my low powered client it s still lagging a bit, I need to get rid of path contains tonight and see.

[hit_ny]

also remember that a search will not inherit your filter search but rather search the hole database and then apply the filter

Are you saying that if child views are set to inherit from a parent that MC --still-- won't carry out the parent search first ?

The implication is that views inheriting from parent are just to simplify search criteria composition in child views rather than actually affecting the order in which the search is executed.

Over the years I've found that optimising queries in MC is really a black art as the idea is to make it easier to use. There are few general guidelines but nothing more beyond that.

Couple of approaches that I've used to some effect
- Only have in the database what will be searched and leave out other supporting files which would needlessly clutter up the database. The idea here is not to use MC as a file explorer but more for what it was designed for ie a media manager.

Using multiple libraries is a subset of this approach but can get unwieldy if overdone.

A further extension of this idea is avoiding large notes fields opting instead for txt files which could be called up using scripts if stored in the same directory as the media. Things have improved over the last cpl of versions with respect to this aspect in particular so its perhaps not as necessary to do as in the past but think of it this way, your library is only going to get bigger over time. It's all going to add up unless you have a 2500+ JR Mark to run MC on.

- using cached custom fields in preference for calculated fields. Meaning saving the product of a calculated field in a cache field and only using the cache field in views so display is much faster.

[HiFiTubes]

What about lyrics fields which can be heavily populated?

Can we disable Documents in Options, or just have disable import of these. Also, a lot of m3u files get sucked into Imported Playlists.

And what about that old db-delete thing; that still valid to look at now?

You mention much with regard to "search"; I assume you also
mean MC simply building a view scheme and a manual search which I don't do as much as browsing schemes.

Also, any thought as to if disabling tree browsing helps? What about having patent filters used but then having the same stock audio only rule in both? MC just ignores the child's extra?

I have a lot more poking around to do, thanks.

Curious if anyone is testing out Library Server vs. Shared Library for speed; should there be any perceptible difference?

I'm considering moving Images & Video to another library to lighten the load for my low-power client; would be neat to have a master filter for Library Server on the client to just pull Audio in from a master library.

[hit_ny]

What about lyrics fields which can be heavily populated?

If your library is under 100k files and you're using a reasonably modern PC it should be fine. I'm guessing you like to have lyrics display in a plugin during playback so losing this ability would be too high a price to pay for faster searching.

If its more than 100k files again what could you live with

Can we disable Documents in Options, or just have disable import of these. Also, a lot of m3u files get sucked into Imported Playlists.

Depends on the number of Documents, a few thousand won't matter, tens of thousands will, in which case putting them in their own library might be better.

m3u files are not needed. Unless they are custom made playlists.

And what about that old db-delete thing; that still valid to look at now?

Don't follow ?

You mention much with regard to "search"; I assume you also
mean MC simply building a view scheme and a manual search which I don't do as much as browsing schemes.

The principle is a smaller library is faster to search than a larger one and applies across the board.

Also, any thought as to if disabling tree browsing helps?

no idea

What about having patent filters used but then having the same stock audio only rule in both? MC just ignores the child's extra?

This is the first question i asked so let's see what lasse_lus says.

I have a lot more poking around to do, thanks.

There aren't too many avenues as the creators want to keep it simple, this is why i referred to tweaking smartlists as a black art as the gains can be illusory or even  placebo. Beyond a few general guidelines the gains are not too significant.

Curious if anyone is testing out Library Server vs. Shared Library for speed; should there be any perceptible difference?

I don't think there is much difference in terms of speed between these two approaches. As in both cases a library is copied over to the client in its entirety. Library server does what used to be done manually in a more transparent fashion. Not to imply that shared library is no longer useful but rather its used for reasons other than speed.

The bigger noticeable difference here would be where the media was stored rather than library response, if it has to be stream off a server vs playing locally.

I'm considering moving Images & Video to another library to lighten the load for my low-power client; would be neat to have a master filter for Library Server on the client to just pull Audio in from a master library.

I don't think this is possible, as the client will pull the master library anyway unless you specify a subset library.

[Lasse_Lus]

Are you saying that if child views are set to inherit from a parent that MC --still-- won't carry out the parent search first ?

 ? i guess you don't follow, matt fixed the queries so now its between 10-50 times faster..

a couple of lines up..

Coming in build 57:

Optimized: Search engine uses more sophisticated logic for deciding the order to evaluate pieces of a database query, providing substantial speed improvements in some cases.

[vagskal]

I have started using pane views with nested list fields and it takes a very long time to open such views. I have one view which takes 1 min. 20 sec. to load. To show the sublevel for one item in the pane takes 3-4 sec.

To open a pane view without nested list fields takes 9-10 sec. with 8 panes all set to a database field (i.e. no expressions directly in the panes). The database fields contains mostly expressions sometimes with a lot of If() functions, for example. Grouping is using a calculated field with this expression:

Code: [Select]

Clean(If(IsEmpty([Date]),Okänt år,FormatDate([Date, 0], Year)) - [Album] If(IsEqual([Genre],Live,7),/[Live/] ,)If(IsEqual([Genre],Compilation,7), /[Comp./] ,)If(IsEqual([Genre],Soundtrack,7), /[Soundtrack/] ,)If(IsEmpty([Album Rating]),, Left(* * * * * ,Math(Left([Album Rating],1)+Left([Album Rating],1)))If(IsEqual(Mid([Album Rating,0],2),5,2),° ,))/(If(IsEqual([iTunes Compilation],1),Blandade artister,If(IsEqual([Compilation],1),Blandade artister,If(IsEmpty([Albumartist]),[album artist (auto)],[Albumartist])))/)
The columns in the views are not calculated but set to a database field.

The database contains 115k files, all are music files and displayed in the initial view. Only two fields (lyrics and reviews) contain larger chunks of text and those are not default search fields or shown in the columns.

I am running a rather powerful PC (JRMark (version 15.0.73): 2132) and was expecting better performance than this even with calculated fields.

I have read this thread and was wondering if someone had any other idea for speeding things up (apart from not making excessive use of nested list fields and fields calculated with complex expressions...).

The 0.5 sec. for a 250k library mentioned earlier in this thread sounds promising, but is not something I have ever experienced.

[Matt]

vagskal, expressions (or calculated fields, which are effectively the same thing) are going to be much slower than normal database fields.  8 panes, each with nested if(...) expressions, for 115k files is just a lot of work.

You might consider using normal database fields when possible, or arranging groupings in some other way than nested if(...) expressions.  You can make a database field that's a snapshot of an expression result.  That field will be much faster, but of course doesn't update automatically.

Less panes or drop panes would also help.

[vagskal]

Thanks for the reply!

I guess MC despite improved performance will just get slower for me in the same pace as I discover all possibilities with MC and learn to write expressions...

You can make a database field that's a snapshot of an expression result.

How is this done? I might consider it at least for my grouping field, which is rather static.

[Matt]

I guess MC despite improved performance will just get slower for me in the same pace as I discover all possibilities with MC and learn to write expressions...

Would you consider sending a library backup to me (matt at jriver dot com) with the view that takes 1:20 to open?  It might help us optimize some code in the expression engine.

How is this done? I might consider it at least for my grouping field, which is rather static.

Create a new field.

Then pick all your files, and edit that field.

Type your expression with a leading equal sign (like Excel).

For example, if you edit a field like:
=[Name] by [Artist]

The value, per file edited, will get filled by things like "The Letter by Joe Cocker".

[vagskal]

Would you consider sending a library backup to me (matt at jriver dot com) with the view that takes 1:20 to open?  It might help us optimize some code in the expression engine.

I have sent you an email.

Create a new field.

Then pick all your files, and edit that field.

Type your expression with a leading equal sign (like Excel).

For example, if you edit a field like:
=[Name] by [Artist]

The value, per file edited, will get filled by things like "The Letter by Joe Cocker".

Thanks for the explanation. If I want to update the values, do I just delete the field and create a new field with the exact same name and =expression or is there an easier way?

[Matt]

If I want to update the values, do I just delete the field and create a new field with the exact same name and =expression or is there an easier way?

Just edit the field again and use =expression.  There is no need to delete or recreate the field.

[vagskal]

I tried the snapshot idea for my grouping field. It might be a snapshot of the values, but it was not taken in just a snap . It took over ten minutes to calculate the values for 115k files. It improved the loading of the views by only about 2 sec. (to 7-8 sec.), i.e. the same loading time as when I set grouping to none. I think this improvement in loading time is not enough for me considering that the trade-off is having a potentially incorrect grouping display. The calculated fields used in my panes must be responsible for a large part of the delay (if I have six calculated fields each responsible for a more than 1 sec. delay I guess it will take some time to load the view even with a quad core PC). Since I often, or mainly, use the panes to find files with tags to correct it would defeat this purpose to use snapshot values in the panes. I guess I will just have to be patient or hope that you come up with some optimization that can keep up with my creativity and all the possibilities provided by MC...

Thanks though for the tip and explanation regarding the =expression field. It might come in handy if I want to save in MC as a backup the state of my tags at a certain point in time (in case I screw up when mass tagging or otherwise). I could save all the tags in the files to just one static field (=Artist|[Artist];Album|[Album];etc.) and do this on, say, a monthly basis as a backup. I guess that would also lead to performance issues in the end, but I can use separate MC libraries as backups and delete that giant field in the master library... Oh, the possibilities provided by MC seems infinite but alas so poorly documented. Have you considered a website where user can upload their libraries, if they want to, for others to see and be inspired by and learn from?

I must add that the application of calculated fields is not only triggered by my creativity but also by the current inability of MC to handle pretty standard tags for both mp3 and flac files (see this enhancement request http://yabb.jriver.com/interact/index.php?topic=56698.msg384787#msg384787). This makes it necessary to combine values representing the same type of rather basic information (Album Artist, Disc Number, Publisher, VA album) contained in two different fields/tags (instead of one unified field supported by MC) into one calculated field.

[Matt]

vagskal, it's hard to claim a real victory on this one but I did get some good speedups out of your library.

The time to load the "Samband" library view (115k files, 8 panes, many with deep expression logic):

Media Center 15.0.80: 19 seconds
Media Center 15.0.xx: 11 seconds
(by the way, this was on a machine that benchmarks about the same as yours, so your report of 80 seconds confuses me)

So a coming build will be about 40% faster showing that view.  Hopefully we'll have an opportunity to spend some more time on this in the future to look for further speedups.

Thanks.

[vagskal]

vagskal, it's hard to claim a real victory on this one but I did get some good speedups out of your library.

The time to load the "Samband" library view (115k files, 8 panes, many with deep expression logic):

Media Center 15.0.80: 19 seconds
Media Center 15.0.xx: 11 seconds
(by the way, this was on a machine that benchmarks about the same as yours, so your report of 80 seconds confuses me)

So a coming build will be about 40% faster showing that view.  Hopefully we'll have an opportunity to spend some more time on this in the future to look for further speedups.

Thanks.

Great, thanks! I look forward to the new build.

With the previous build (.73, I think) I definitely clocked that view to about 80 sec. and I tried it twice with the same result. Now, I have installed the new build (.80) and I get about 20 sec. like you. Did you perhaps do some magic optimization between those two builds?

As far as I can tell it is only the loading of that view (with the nested list fields) that is faster with .80. Displaying a sublevel in that view takes 3-4 sec. as before and loading the Artist/Kompositör Pane view, which was the one I clocked before, still takes about 10 sec. (or actually 12 sec. when I clocked it now with .80). Do you get the same numbers or are also the Artist/Kompositör Pane view faster on your PC? When I did the clocking MC had been running for days and I had added/changed a lot of fields etc. Could that have something to do with it?

MC and its database is on a fast SSD disc. The music files are on a usb disc and I have set MC to update for external changes.

Once again thanks for your quick response.

[vagskal]

Great, thanks! I look forward to the new build.

With the previous build (.73, I think) I definitely clocked that view to about 80 sec. and I tried it twice with the same result. Now, I have installed the new build (.80) and I get about 20 sec. like you. Did you perhaps do some magic optimization between those two builds?

As far as I can tell it is only the loading of that view (with the nested list fields) that is faster with .80. Displaying a sublevel in that view takes 3-4 sec. as before and loading the Artist/Kompositör Pane view, which was the one I clocked before, still takes about 10 sec. (or actually 12 sec. when I clocked it now with .80). Do you get the same numbers or are also the Artist/Kompositör Pane view faster on your PC? When I did the clocking MC had been running for days and I had added/changed a lot of fields etc. Could that have something to do with it?

MC and its database is on a fast SSD disc. The music files are on a usb disc and I have set MC to update for external changes.

Once again thanks for your quick response.

After having used MC for about a day (but not changing any fields as far as I can remember) I switched to the Samband view again and noticed that it did not appear as "fast" as it did the last time I accessed it so I clocked it again and this time it took 31 sec. for it to appear (instead of the 20 sec. I reported above). I then quit and restarted MC and after that it took "only" 20 sec. again for that view to appear. The other views with a loading time of 10 sec. or less had about the same loading time as when I had used MC for about a day.

[Lasse_Lus]

matt, this is really interesting 

this improvement is for a lot of files with expressions, i don't have many of those views, but is it possible to improve the perfomance of showing a lot of files ? or is this a limitation ?..let say 500 k files in one view, or do you need the latest hardcore CPU with very fast disks ?

i was thinking this for me with quite limited resources, i load my large view (with all my files), i can wait let say 10-15 seconds thats no problem...after that i select within the pane..and i get fast answers..but if i reset the view i have to wait 15 seconds again..so could a view be (snapshot) cached ?

thanks for your fantastic work

[vagskal]

vagskal, it's hard to claim a real victory on this one but I did get some good speedups out of your library.

The time to load the "Samband" library view (115k files, 8 panes, many with deep expression logic):

Media Center 15.0.80: 19 seconds
Media Center 15.0.xx: 11 seconds
(by the way, this was on a machine that benchmarks about the same as yours, so your report of 80 seconds confuses me)

So a coming build will be about 40% faster showing that view.  Hopefully we'll have an opportunity to spend some more time on this in the future to look for further speedups.

Thanks.

I just wanted to tell you that I have now tried out the new .87 build and the loading time with a freshly started instance of MC for the most complicated menu ("Samband" with many panes and nested list type fields) is down by some 50% (from 20 sec. to about 10 sec.). The loading time for other menus with many panes but hardly any nested list type fields is improved from around 10 sec. to around 7 sec.

Thank you! And good luck with your work on further speedups.