Performance: NFS shares are slow to list tags

[GoogleCodeExporter]

i am a quodlibet user and am experiencing laggy behavior while listing
meta-data for a nfs share. the nfs share is not slow to browse, so its not
a network problem. 

here is the post i made on the quodlibet google-code page and they
explained that the issue may be with mutagen instead. 

----------

i have some music mounted over nfs, and i do not want to add it to my
library. i  just play it through the filesystem browser. 

this works, but is very slow to load a directory's contents into the
tracklist pane (to the right of filesystem tree pane). 

the filesystem tree browses quickly, the lagginess is just in the
tracklisting pane.

the nfs mount can be browsed quickly with other applications, so i think it
is a quodlibet specific problem. 

----

if there is a way to isolate and troubleshoot the mutagen part of it i
would be glad to help. 

thanks
alex

Original issue reported on code.google.com by alexande...@gmail.com on 17 Sep 2009 at 7:32

[GoogleCodeExporter]

What's an example of an application that browses it quickly?

Original comment by joe.wreschnig@gmail.com on 19 Sep 2009 at 9:59

[GoogleCodeExporter]

Original comment by joe.wreschnig@gmail.com on 19 Sep 2009 at 10:05

• Changed title: Performance: NFS shares are slow to list tags

[GoogleCodeExporter]

nautilus browses normally. 

Original comment by alexande...@gmail.com on 19 Sep 2009 at 11:25

[GoogleCodeExporter]

Can you compare, e.g. "file *.mp3" vs. "mutagen-inspect *.mp3" on a group of 
files,
on NFS and off NFS? Please run it twice to account for caching.

Original comment by joe.wreschnig@gmail.com on 21 Sep 2009 at 7:58

[GoogleCodeExporter]

ok i've noticed some strange hard-to-reproduce behavior, which seems to be 
connected
to some kind of cacheing. i wrote this one-liner to give me a quantifiable 
number on
how long it both file and mutagen-inspect to run;

so on a local folder:

> T_START=`date +%s`; mutagen-inspect *.mp3 >> /dev/null; T_STOP=`date +%s`; 
echo $((
T_STOP - T_START ))
0
> T_START=`date +%s`; mutagen-inspect *.mp3 >> /dev/null; T_STOP=`date +%s`; 
echo $((
T_STOP - T_START ))
0

and this is repeatable (always <1s). if i run it on a nfs folder:

> T_START=`date +%s`; mutagen-inspect *.mp3 >> /dev/null; T_STOP=`date +%s`; 
echo $((
T_STOP - T_START ))
18
> T_START=`date +%s`; file *.mp3 >> /dev/null; T_STOP=`date +%s`; echo $(( 
T_STOP -
T_START ))
1
> T_START=`date +%s`; mutagen-inspect *.mp3 >> /dev/null; T_STOP=`date +%s`; 
echo $((
T_STOP - T_START ))
0

[cd to a different folder]

T_START=`date +%s`; file *.mp3 >> /dev/null; T_STOP=`date +%s`; echo $(( T_STOP 
-
T_START ))
16

mutagen-inspect somtimes takes long times (10-40s) to finish. but once its done 
i can
re-list it in <=1s. also, some directories take <=1s to list their first time. i
havent been able to determine why.  file *.mp3 exhibits the same behavior, so i
conclude that its the nfs share, and not mutagen. 

Original comment by alexande...@gmail.com on 22 Sep 2009 at 1:47

[GoogleCodeExporter]

Nautilus only needs to look at one file, the directory, to get the list of 
things in
it. Mutagen (and file) both need to look at the actual contents, which 
obviously will
take more time. If Mutagen is on par with file, then I don't think there's an 
issue here.

Original comment by joe.wreschnig@gmail.com on 28 Sep 2009 at 4:29

• Changed state: Invalid