changed: Improve performance (considerably) when browsing streamed (inte... #1944

Merged
merged 1 commit into from Dec 17, 2012

Projects

None yet

3 participants

@arnova
Member
arnova commented Dec 16, 2012

...rnet) filesystems + increase dir cache size. The performance of streamed filesystems compared to Eden is terrible in Frodo. While browsing such filesystems in the GUI feels really slow. The reason is that our backgroundinfo/thumb-loader check for more art types now and thus hit the filesystem more often with Exists() calls, which are insanely slow with Curl. To workaround this we first cache the item's directory before checking for local (art) file existance. I also increased the directory cache size a bit as I don't think there are any platforms should have problems handling bigger sizes. Perhaps we should consider doing this for all filesystems and perhaps even increase the MAX_CACHED_DIR to an even higher value?

Since it's a regression from Eden, and the performance gain is huge, it would be nice if this could still be included for Frodo.

@jmarshallnz
Member

Isn't the directory cached anyway with the exception of folder items? So it could be restricted to if (item.m_bIsFolder). Once done, there is no need at all to increase the amount of cached directories.

Do you have a lot of files with no art, or do most files have art? Reason I ask is that rearranging the check for cached art would make things quicker - we check for local art only if we have no art, but we could change it to only check once.

Lastly, why is performance of browsing increased - this is done in the background.

@arnova
Member
arnova commented Dec 16, 2012

The problem is that we don't cache the stuff in sub-folders. So when you have:

  • dir/subdir1
  • dir/subdir2
  • dir/subdir3
  • ...

and enter "dir", we check for folder art in all subdir's, which are not cached. In my case this is terribly slow as they have no (db) art assigned so XBMC will look for poster|fanart|banner.jpg existance in all of those subfolders. I probably should have explained that the performance problem specifically occurs when entering a new directory, since the backgroundloader is still accessing the Curl filesystem (although it's about to terminate), getting the new Curl directory is really slow. By caching the directories in the ThumbLoader thread, the directory access from the main thread doesn't have to wait for all the queued Exists()-call from the ThumbLoader thread.

@jmarshallnz
Member

Right, so add the check for item.m_bIsFolder. Further, specifically comment why it's there so we don't remove it later.

@arnova
Member
arnova commented Dec 16, 2012

Done. And what about the number of cached directories? Is 30 ok (what's the maximum amount of subdirs most users have) ? I think we can make it fairly large without draining too much memory and/or cpu.

@jmarshallnz
Member

I see no reason to change it from 10. There's no benefit once you've passed the current one except for the case where you have enough to hold all subdirs in addition to whatever is going on elsewhere.

@arnova
Member
arnova commented Dec 16, 2012

Agreed, removed the commit that changes the amount from 10.

@arnova
Member
arnova commented Dec 17, 2012

@jmarshallnz (or @davilla ): Can this be merged (be)for(e) Frodo?

@davilla
Contributor
davilla commented Dec 17, 2012

@jmarshallnz, if ok with you. inject

@jmarshallnz jmarshallnz merged commit aea3308 into xbmc:master Dec 17, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment