[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [emms-help] Album artist grouping in emms-browser
From: |
Pierre Neidhardt |
Subject: |
Re: [emms-help] Album artist grouping in emms-browser |
Date: |
Sun, 22 Apr 2018 12:25:34 +0530 |
User-agent: |
mu4e 1.0; emacs 26.1 |
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