[vlc-devel] [RFC] Directory access: use a decent insertion order

[Rémi Denis-Courmont]

Le dimanche 14 février 2010 00:49:46 Antoine Cellerier, vous avez écrit :
> On Sun, Feb 14, 2010, Rémi Denis-Courmont wrote:
> > Le dimanche 14 février 2010 00:04:28 Antoine Cellerier, vous avez écrit :
> > > I'd like to modify the directory access to make it insert
> > > file in alphabetical order instead of the current "random"
> > > order (well, natural sort order, not really alphabtical.
> >
> > AFAICT, unless you've randomized the playlist, the order is whatever the
> > filesystem uses (which is not random). At least mpg123 and ogg123 exhibit
> > the same order.
> 
> Which isn't to say that it's the right order from a human user's point
> of view. The filesystem ordering scheme isn't random but it's still
> completely illogical when all you consider is the filename. All software
> which list files in directories, like your nautils (or kde equivalent),
> explorer, finder, rythmbox, firefox, etc always sort it decently by
> default.

*Not* $(find). The explorer is not-recursive, which makes the task much less 
heavy on the system.

> Sorting of the directory nodes wouldn't add any significant overhead (it
> could even be coded to reduce the numper of asprintf psz_xspf_extension
> string concatenations and thus probably reduce the total runtime).
> Sorting of the items would probably be possible fairly easily too. All
> you need to sort is the <extension> tree structure bit. I'll code a
> small prototype tomorrow.

The problem is not sorting. The CPU is fast.

You need to keep the full list of files in every directory that you recurse 
through, which takes a lot more memory than at the moment.

But what I'm most afraid is the I/O. Currently, one Block() call = one 
readdir() call, so the I/O latency is as short as possible. To sort a 
directory, you need to read it all, and then sort it and then output. And that 
will have much much longer latency for large directories.

> > (*) The guy who designed the tree structure inside VLC extension to XSPF
> > probably did not understand how XML works. This is completely brain
> > damaged.
> 
> Agreed ... but then you have to consider all the XSPF related
> constraints (like needing a flat playlist since your .xspf file needs
> to be compatible with other parsers which don't implement the VLC
> extensions). You could always ask Yoann :-)

Supporting XSPF import/export is one thing. Using it as our native format when 
it does not handle tree is another.

I don't need to mention that this "extension" has already been responsible for 
a Common Vulnerability and Exposure, IIRC.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis