Topic: Slow areas in MC 9.1 (Read 8437 times)

dragyn · « **on:** September 02, 2003, 12:34:26 am »

Here is my list of some slow areas in MC. This only applies to ppl with large libraries as you won't see any real slowdowns with a few files. (less than 10,000 is a few files in this case)

Search

Auto-searching takes forever and a half to display anything as it searches almost on every letter key. My solution would be this:

Have a menu item at the bottom of the search right-click menu called 'auto search'. When clicked, it does the same as now. When unclicked, it waits for the enter key to be pressed before doing anything.

Playlists
When I have a playlist based view scheme, it seems that it takes a long time to display anything. Even if it just a few files.

View Filter
If I'm in a view scheme when a 'filter' is applied, it seems that MC re-reads the filter after double-clicking a song. This causes a huge slowdown in the player window as it takes 15-45secs to display the info and to do other things, like volume.

Videos
Playing a video outside of MC seems to take forever. I don't know what MC is doing but the video will almost be done before I even see it. MC also starts the video, then goes to fullscreen. I think it should be the other way around as I want to see the beginning of the file, not when it's over half done.

Thumbnails
You guys have gotten better in this area (especially in closing) but when going into a view scheme with lots of files, MC just sits there as it seems it's trying to display every file at once. MC becomes locked and can't switch to anything else right away like 'Playing Now'.

(note: all thumbnails have been created for every file in the database)
----

There are way too many times that MC just sits there. I have no idea what it's doing because there's no indicator. It feels like its frozen into place.

dragyn · « **Reply #1 on:** September 02, 2003, 12:54:57 am »

Just for the record, I currently have 123,573 files in the database. I was gonna break that down into [media type] but that's not an option in statistics.

I know I don't have the fastest machine out there. MC is also fast in a lot of other areas so this tells me it's either a bug in the code somewhere, or MC is doing too much and not letting the user switch to anything else till it's done (frozen).

Hopefully some of these issue will be addressed before release time.

JimH · « **Reply #2 on:** September 02, 2003, 03:50:07 am »

dragyn,
Is there a network drive involved? It could be a bug somewhere else.

nila · « **Reply #3 on:** September 02, 2003, 04:20:05 am »

Dragyn - to break down into types do this:

Select the root of 'Media Library'

Go to the search box and type in:

[Media Type]=[audio]
[Media Type]=[image]
[Media Type]=[video]

and then just look at the statistics for the search results (another great example of when the TREE comes in useful).

I'd love to see a breakdown of your files because that is a LOT!!

Sauzee · « **Reply #4 on:** September 02, 2003, 06:08:26 am »

I've got about 22,000 files in my library and notice slowdowns when I go to the root of the smartlists section of the tree.

If I go directly to one of the smartlists there isn't a slowdown.

Matt · « **Reply #5 on:** September 02, 2003, 07:51:25 am »

Searches on basic fields (not calculated, not formatted) are the fastest. Also, square brackets help the speed by narrowing the amount it searches.

So for your view filter, try something like [Filename]=[c:\" instead of [Filename (path)]=c:\

Thanks for this thread. We'll see what we can on our end.

dragyn · « **Reply #6 on:** September 04, 2003, 05:07:33 pm »

I have a lot of files across the network. I have 3 computers in the database. I do see the slowdown with local files aswell.

Just wondering..

Does the "check if file exists" feature have any impact on the list being created? It obviously must see if the file is there or not on the disk. Having 20-40k of files loading at once must do some impact on performance...or not?

I'm still seeing a slowdown on just playing a few music files (245). It lags about 10secs or so. It just seems like it's stuck on something.

Matt · « **Reply #7 on:** September 04, 2003, 05:33:24 pm »

The "check if exists" only runs once as the files are painted, so it's only like 20 at a time.

Does the new statusbar outputs tell where it's hanging up?

Do views without panes or different Action Window pages help / hurt the speed a lot?

BTW, does 245 feel any fasterer? Thanks Dragyn.

Polonio · « **Reply #8 on:** September 04, 2003, 05:56:01 pm »

Quote

The "check if exists" only runs once as the files are painted, so it's only like 20 at a time.

While a slow scrolling, the list scrolls one file at a time. It seems a bit slow. Also, while a fast scrolling, the list repaintaing is wierd.

I dont know if "check if exists" is causing that. If so, may be worth do not check if exists so often (may be, just once per file and session).

I did a test: I renamed a folder, and the MC list detected it inmediatelly (no need to change scheme or reselect in panes...). I do know if "check if exists" is that important.

BTW, I do not feel I have a speed issue. I have about 4000 songs, and response time is ok (specially if I compare it with any other app...).

dragyn · « **Reply #9 on:** September 04, 2003, 08:15:06 pm »

It's just gotta be my system and all those files.

If View Filter is off, it works pretty good. If I hide a path, it takes awhile to update. I used [] in the rule list. It does speed things up a bit.

The status bar isn't doing anything when it slows down. I'm not even opening anything. It's just when playing files. It starts right away, then it's 'frozen' for about 5-10secs or so...just the display, not the song.

jleerigby · « **Reply #10 on:** September 04, 2003, 09:57:00 pm »

View schemes featuring panes with calculated fields take about 25% longer to load. 245 is faster except in this area.

Matt · « **Reply #11 on:** September 05, 2003, 01:13:29 pm »

9.1.246 should be faster again. Let us know how we're doing...

jleerigby · « **Reply #12 on:** September 05, 2003, 03:41:52 pm »

Will do. 246 Sounds great but won't get to try it for a few days. Spending the weekend in Whitby - famous for giving the world captain James Cook and the Endeavour - who was famous for giving us Hawaii and Australia amongst other places.

Anyway, this weekend it'll be famous for beer and watching England beat Macedonia at football (sorry - Soccer!).

http://www.whitbyonline.co.uk/gallery/whitby_46/

matshif · « **Reply #13 on:** September 05, 2003, 03:46:37 pm »

Quote

Anyway, this weekend it'll be famous for beer and watching England beat Macedonia at football (sorry - Soccer!).

Hope so and that Sweden beat San Marino

Mats

jleerigby · « **Reply #14 on:** September 05, 2003, 11:36:35 pm »

Definitely faster.

I still have one view scheme though that takes about 5 seconds to load. The VS rule is
[Media Type]=[Audio] -[Album]=[] -[Album Artist (auto)]=[(Multiple Artists)]

It's a sub to a VS Group that has a rule of
[Media Type]=[Audio] -[Album]=[] ~sort=[Album],[Track #]

Both the VS & VS Group have panes of
Genre, Album Artist (Auto) (6), Album Artist (Auto) (1),Album Artist (Auto), Album.

Both are set to Album Thumbnails.

The VS Group loads quicker - 4 secs. The VS is slower 'cos is takes longer 'Loading Panes'. This is really not a problem for me as general browsing amongst view schemes and around MC is much quicker now. I just thought you'd appreciate the info.

Great job on the last couple of builds. Thanks to all the team.

jleerigby · « **Reply #15 on:** September 05, 2003, 11:49:14 pm »

You know when you post some info and it immediately gets you thinking ?

Just done a little experiment which got my VS load down a massive 2 secs from 5 to 3 secs. All I did was remove tick against the 'Honor parent scheme search strings' and I added the extra strings to the child VS (i.e. the sort).

Now why is it taking so much longer just 'cos it has to read the extra strings from a VS group.

dragyn · « **Reply #16 on:** September 07, 2003, 05:40:47 am »

Nothing really has changed. I've been waiting about ~3-5mins now waiting for mc to become responsive again.

I don't think it has anything to do with the status bar logs. I think it's something before that. There is a delay time.

What is it doing?

Matt · « **Reply #17 on:** September 08, 2003, 06:36:43 am »

How about the speed of thumbnails vs. details?

How about in a playlist with no panes?

How about with only one column visible?

We have to isolate what is taking the time. Thanks Dragyn.

dragyn · « **Reply #18 on:** September 08, 2003, 01:23:18 pm »

I'll do some more testing and let you know what I come up with. Thanks for looking into this.

geoelectric · « **Reply #19 on:** September 08, 2003, 08:24:40 pm »

I happened to try 9.0 today (I'm new enough that I jumped right into 9.1) and found that the library import was maybe 2-3x as fast in the older version, at least on mp3s.

What's it doing in 9.1 that slows it down so much? Is it configurable?

PhDSM · « **Reply #20 on:** September 08, 2003, 10:48:26 pm »

Hello,

As I indicated in the 9.1.244 thread. I experience the same performance issue with 9.1.
I have 16000 entries database and response time was great with the same database in 9.0. There is a significant difference between this 2 version.
What make them so different in term of performance ?
Rgds
Phil

RhinoBanga · « **Reply #21 on:** September 08, 2003, 11:18:17 pm »

Quote

We have to isolate what is taking the time. Thanks Dragyn.

Matt,

Can't you put in trace statements in your code that appends the current processor time to a flat file somewhere?

That would make it simple to locate where the issue is and save us having to try and describe where we think it is.

dragyn · « **Reply #22 on:** September 09, 2003, 03:30:32 am »

Decided to start fresh. Unistalled, Reintalled. New Library, etc.

Started importing. MC will still crash when importing files. When I reimport, it seems to work again. So would this be a file issue or an MC issue?

Does MC check the library after a crash? If MC crashes during an import, does it screw up the database?

I also had some image files with ? x ? dimensions (no image). These files are not viewable in explorer either..probably just corrupt files I guess but they still get imported in MC. Also, I was using a HUE changer on a couple files...these files were not viewable by explorer but were viewable in the program (not MC). Different compression? I don't know much about it.

I was gonna try 222/223 again because after that build is when I started seeing huge slowdowns but decided not too. Also note that this crash when importing bug was first noticed after the import counter was added to the 'importing files dialog'

dragyn · « **Reply #23 on:** September 11, 2003, 04:38:10 pm »

I think I've narrowed this down to a memory leak. After a reboot, everything seems fine. But if I leave MC running for a while, it gradually gets slower and slower. When I exit MC, it's still slow. Doesn't seem to happen if I never start MC.

I'm thinking it's a leak in the skinning engine.

Thoughts?

Matt · « **Reply #24 on:** September 11, 2003, 06:00:09 pm »

You should be able to see leaks by watching Task Manager. (you may have to turn on some extra columns)

To the best of our knowledge there are no leaks in MC. (GDI, memory, or handles) If you find any, please let us know.

Could something else be rotting the OS with time?

jleerigby · « **Reply #25 on:** September 11, 2003, 11:40:23 pm »

Quote

I think I've narrowed this down to a memory leak. After a reboot, everything seems fine. But if I leave MC running for a while, it gradually gets slower and slower. When I exit MC, it's still slow. Doesn't seem to happen if I never start MC.

I'm thinking it's a leak in the skinning engine.

Thoughts?

To narrow it down I'd start with disabling plug-ins within MC.

geoelectric · « **Reply #26 on:** September 12, 2003, 03:39:18 pm »

I'm finding that tag editing has ground to a halt in my library. I'm trying to assign dates to all my albums. It started off quickly. At first I couldn't see the "Writing Tags" dialog. Then I could see it flicker. Now it's up to a couple of seconds per track to write the date tag. Restarting MC hasn't helped.

This is beta 251.

geoelectric · « **Reply #27 on:** September 12, 2003, 03:57:55 pm »

So, tagging is -very- slow if the file has an album cover embedded. It's only kind of slow if the file doesn't. When I first started out doing the tagging, though, it was tagging imaged and unimaged files at normal speed. I have images set to be stored in the files.

jleerigby · « **Reply #28 on:** September 12, 2003, 11:49:03 pm »

Quote

Just done a little experiment which got my VS load down a massive 2 secs from 5 to 3 secs. All I did was remove tick against the 'Honor parent scheme search strings' and I added the extra strings to the child VS (i.e. the sort).

Matt - Have you had a look at this? I thought it was quite a breakthrough to find I could improve VS load time for this particular scheme by 60%.

dragyn · « **Reply #29 on:** September 13, 2003, 05:08:25 am »

Quote

Just done a little experiment which got my VS load down a massive 2 secs from 5 to 3 secs. All I did was remove tick against the 'Honor parent scheme search strings' and I added the extra strings to the child VS (i.e. the sort).

I've noticed a huge speed up when doing this also but it not the problem I have.

I've noticed this happens with thumbnails. If I view a lot of files, the memory keeps going up (until 100MB or so) then it drops way down, then it displays the thumbs. This is the wait time I'm haiving.

jleerigby · « **Reply #30 on:** September 15, 2003, 11:15:58 pm »

Quote

Matt - Have you had a look at this? I thought it was quite a breakthrough to find I could improve VS load time for this particular scheme by 60%.

b b b b b b b b b uuuuuuuuuu mmmmmmmm p

jleerigby · « **Reply #31 on:** September 15, 2003, 11:16:59 pm »

Quote

Matt - Have you had a look at this? I thought it was quite a breakthrough to find I could improve VS load time for this particular scheme by 60%.

b b b b b b b b b uuuuuuuuuu mmmmmmmm p

Matt · « **Reply #32 on:** September 16, 2003, 06:44:24 am »

There should only be a speed difference if your search strings have post-process commands. (the things with tildes ~) In those cases, MC has to evaluate the searches one after the next instead of together.

If it doesn't look like it's working that way, let us know what search strings you're using and we'll do some testing.

jleerigby · « **Reply #33 on:** September 16, 2003, 08:21:38 am »

Matt - The detail is in some previous posts quoted again below. From what you say it's the sort that's causing the slowness. It's quicker to do a sort when the rule is in the VS itself. If the rule is in the parent VS group it really slows it down. So I guess the lesson here is not to put tildes in view scheme groups and set the child VS to honor the parent - unless of course you can optimise this.

Quote

I still have one view scheme though that takes about 5 seconds to load. The VS rule is
[Media Type]=[Audio] -[Album]=[] -[Album Artist (auto)]=[(Multiple Artists)]

It's a sub to a VS Group that has a rule of
[Media Type]=[Audio] -[Album]=[] ~sort=[Album],[Track #]

Both the VS & VS Group have panes of
Genre, Album Artist (Auto) (6), Album Artist (Auto) (1),Album Artist (Auto), Album.

Both are set to Album Thumbnails.

The VS Group loads quicker - 4 secs. The VS is slower 'cos is takes longer 'Loading Panes'.

Quote

Just done a little experiment which got my VS load down a massive 2 secs from 5 to 3 secs. All I did was remove tick against the 'Honor parent scheme search strings' and I added the extra strings to the child VS (i.e. the sort).

dragyn · « **Reply #34 on:** September 19, 2003, 02:31:26 am »

Maybe the problem is MC is trying to load all the images at once? When you have like 10,000 files in the list, that's what seems to be happening. MC becomes stalled.

I know in Explorer, it only loads the thumbnails for what's visible until you move the screen again.

Matt · « **Reply #35 on:** September 19, 2003, 06:59:28 am »

Quote

Maybe the problem is MC is trying to load all the images at once? When you have like 10,000 files in the list, that's what seems to be happening. MC becomes stalled.

It loads them as you need them, so that shouldn't be the problem.

It does have to "Analyze Thumbnails..." (in the status bar) to know what to do in the thumb building thread. If this is what the status bar says for a long time while it's not responding, let us know and we'll work on it.

Thanks!

dragyn · « **Reply #36 on:** September 19, 2003, 04:56:12 pm »

It's just gotta be my pc. I know it's slow. So I'll just leave it as that.

Thanks for helping me on this. MC has gotten faster since I started this topic.

jleerigby · « **Reply #37 on:** September 19, 2003, 10:25:31 pm »

Quote

Thanks for helping me on this. MC has gotten faster since I started this topic.

Ditto.

dragyn · « **Reply #38 on:** September 20, 2003, 06:30:56 pm »

One last thing yet..

I've noticed this slow down is not when viewing thumbnails, sorting lists, displaying views. It happens afterwards.

I was viewing some images earlier and decided to play some tunes. Switch to my Audio scheme, loaded fast. Double-Clicked a song and it too 2mins before the song started. It took another 2mins to display the info at the top. MC usage is high. No other programs running at the time.

That's where the slowdown is. Again, has nothing to do with loading views.

Another thing...

When clicking on a scheme, and then quickly clicking on another, MC has to wait to load the previous scheme before switching. It's like it needs to do it in order instead of just switching right away.

Same goes with viewing files in Full screen. It needs to update a hidden list before the next image shows. If I'm in Playing Now before viewing Full Screen, it's fine.

Overall performance seems slow because MC has to finish what it's doing. It just not a click and go. If I'm in a view scheme, I have to wait for that view scheme to load even though I clicked 'Playing Now'...then I have to wait for that list to show. That's why it seems frozen all the time.

See what I'm getting at?

Matt · « **Reply #39 on:** September 22, 2003, 07:11:52 am »

Quote

I was viewing some images earlier and decided to play some tunes. Switch to my Audio scheme, loaded fast. Double-Clicked a song and it too 2mins before the song started. It took another 2mins to display the info at the top. MC usage is high. No other programs running at the time.

Good find. With 100,000 images playing it took almost a minute to start an audio file on my 2.6 ghz. Next build that'll be more like a few seconds.

We'll try to optimize a few of the other bottlenecks when using that many images.

Thanks Dragyn, and give us an update after next build.

dragyn · « **Reply #40 on:** September 23, 2003, 02:25:05 am »

This definately sped thing up for thumbnails. Now I have the other problem posted before.

I have a smartlist that only has about 8000 files in it based on [Filename (path)]. When hiding this playlist, MC takes a liitle bit to show lists/thumbs and when double-clicking on them, the display area also lags (about 30secs) because it seems MC is rereading the list again.

Does MC have to reread the smartlist everytime you go into a scheme? Is there a way to have fixed smartlists only read into memory once, like [Filename], [Track #], etc. Only reread the smartlist that change like [Date Imported], [Last Played], etc?

I don't know exactly how this works.

INTERACT FORUM

Author Topic: Slow areas in MC 9.1 (Read 8437 times)

dragyn

dragyn

nila

dragyn

dragyn

jleerigby

jleerigby

jleerigby

jleerigby

dragyn

dragyn

dragyn

dragyn

jleerigby

jleerigby

dragyn

jleerigby

jleerigby

jleerigby

dragyn

dragyn

jleerigby

dragyn

dragyn