Load mp3s can take a long time over a network

From https://java.net/jira/browse/JAUDIOTAGGER-401

On Android, and I'm finding that loading 200 MP3 files to just check for the presence of a tag takes around 50 seconds or so.

[code] AudioFile f = AudioFileIO.read(file); Tag tag = f.getTag();

// TODO: support multiple field types

return tag.hasField(FieldKey.GROUPING); [/code]

Additionally, after each file is loaded, I get GC messages talking about large (in Android terms at least, on order of a few Megabytes) allocations/deallocations. Something like:

07-05 02:49:07.438: D/dalvikvm(31373): GC_EXTERNAL_ALLOC freed 207K, 43% free 3265K/5639K, external 0K/0K, paused 34ms 07-05 02:49:07.829: D/dalvikvm(31373): GC_CONCURRENT freed 176K, 41% free 3470K/5831K, external 4K/516K, paused 3ms+3ms

Looking at my log messages, it takes ~400ms or more to load each file.

Glancing at the source code, I note that in MP3File.java, the File instance is passed to no less than 4 functions, each of which may pass the File instance to 1 or 2 other functions. Each function that gets the File instance, typically creates either a FileInputStream or a RandomAccessFile object. Glancing at their constructors (for Android, anyways), it appears each time you create one of these objects that it performs an open operation on the file, and then later on the file gets closed. So this amounts to 8 to 10 open/close operations on each file – and that's just for creating the object.

Now, I'm not a java expert so the rules may be different, but it seems to me that opening a file is a (relatively) expensive operation since you have to go down to the operating system kernel to complete the operation. Particularly on a network, when you have to go out to the server each time that you open the file.

Perhaps a good fix for this would be to change the routines to just use a single file stream (or randomaccessfile object), and close it when it's done with it? That would probably remove a ton of unnecessary overhead. Is there a good reason to not change it to this?

Comments (1)