Petteri Hintsanen <[email protected]> writes: > Pierre Neidhardt <[email protected]> writes: > >> Petteri Hintsanen <[email protected]> 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
_______________________________________________ Emms-help mailing list [email protected] https://lists.gnu.org/mailman/listinfo/emms-help
