Re: [emms-help] Album artist grouping in emms-browser

[Pierre Neidhardt]

Petteri Hintsanen <address@hidden> writes:

> Pierre Neidhardt <address@hidden> writes:
>
>> Petteri Hintsanen <address@hidden> writes:
>>
>>> Caching in general is not particularly smart at the moment.  Also the
>>> metadata extraction could be orders of magnitude faster by batching; now
>>> there is one exec per track.
> ...
>> The main bottle neck was with later-do which pause 0.5s every track.
>> I've added some batch-processing there.  See my recent commit on later-do.
>
> I see.  But there still is one process invocation per track?  I would
> prefer a design where metadata extractor would accept multiple track
> file names and output tags for them in a batch.  This would be easy to
> do with emms-print-metadata via simple stdin / stdout.  Of course it
> requires some modifications to the elisp side, and things have to be
> backwards compatible so that other info methods still work.

I initially went down that road before patching later-do: I implemented
multiple argument support for emms-print-metadata and only then I
realized it was not the bottleneck.
In fact, emms-print-metadata is extremely fast and adding batch support
to it would only result in a negligible performance boost.

Emms' design makes batch processing even more impractical: the first
thing all the file-query-functions (`emms-add-file',
`emms-add-directory', etc.) do is to split the file queue into
individual files before sending them down a long sequence of functions
all of which can only work on individual files.  At the very end of the
function sequence waits the dreaded `later-do'.

Changing this design would imply a lot of refactoring... For little
benefit I believe.

--
Pierre Neidhardt

signature.asc
Description: PGP signature