I’m having an issue with the performance of the path formats I’m using with the beets-alternatives plugin. Updating the alternative is incredibly slow (literally 2-3 seconds per track!). Admittedly, it’s a complex set of formats, with many queries and multiple plugins involved adding fields and functions, so the root cause could be almost anything, or just the accumulation of time due to the indirections I added to attempt to make it easier to maintain the formats.
I’m wondering if implementing all the logic in a smaller set of python functions and doing less in path formats and through field indirections would be my next best step, if there’s no good benchmarking options.
Most likely it’s one of my plugins or the number of indirections in order to make it readable that are causing the problems, but I’m wondering if we have any mechanisms for benchmarking of path format processing?
Very interesting! It would be fascinating to know exactly where the time is being spent… any interest in trying to run a Python profiler (like cProfile) that should be able to detect exactly where in the code is being slow? That might lead to suggestions about what to change to avoid the bottleneck.
I did some non scientific tests. Path formats indeed ate up performance.
I have a very precise renaming scheme that relied heavily on regex. Moving it over to python made it “conservatively, 2x faster” on my machine. You can see the code before and after at the link.
i’ve moved all my album fields to a single python inline call. is there something about inline that might cause poor performance invoking 10ish functions? 8ish of them are very basic 5 line string manipulation functions. is compile_inline the culprit? Edit: Or maybe commenting out aunique does it? Or the regex in the path formats?
Related (can also search github/here for ‘performance’, ‘path format’ etc)