chrisjj
February 21, 2010, 2:59pm
1
Since the addition of filter expressions in V2.44d, the filter is about 6x slower than before.
E.g. on 17044 tracks, I filter on 278 barcode numbers using
* MATCHES 00008637209025|00008637211721|00008637215521|00008637215927|...
On V2.44 this takes about 1min 40sec. On V2.45a this takes about 12min!
Please could the original performance be restored? Thanks.
dano
February 21, 2010, 3:26pm
2
I think you can speed it up greatly with
HAS 00008637209025 OR * HAS 00008637211721 OR * HAS 00008637215521 ...
chrisjj
February 21, 2010, 4:17pm
3
Thanks - good discovery! That speeds it to 50sec.
Florian, could you please implement this in the app?
Florian
February 21, 2010, 7:21pm
4
You mean whether there is an non-regex equivalent of an arbitrarily complex regular expression? Seriously not.
chrisjj
February 21, 2010, 7:36pm
5
Fair enough. Perhaps then the root cause is visible and fixable? It is surprising to find a simple change in syntax ("* MATCHES") has had such a detrimental effect on performace.
Florian
February 21, 2010, 7:48pm
6
* MATCHES applies the same
regular expression on all tag fields of your files. This is a costly operation.
If the barcode numbers are stored in a specific field in your files field MATCHES would only check the specific field. The same applies to the HAS keyword.
chrisjj
February 21, 2010, 8:36pm
7
* MATCHES applies the same regular expression on all tag fields of your files. This is a costly operation.
Well sure - no surprise it took a couple of minutes before. But why has it just got 6x slower?
If the barcode numbers are stored in a specific field in your files
Sadly not.
field MATCHES would only check the specific field.
Understood and indeed that is not as slow (3min40s) but is still much slower than before.
Florian
February 22, 2010, 7:47pm
8
This is indeed weird. I'll have a look at it and optimize it for the next version.
chrisjj
February 22, 2010, 8:30pm
9
I really hope you can prioritise the 6x speed loss Florian, since that is the far more serious one.
Florian
February 27, 2010, 1:16pm
10
This is now fixed with Mp3tag v2.45c .
Just curious: have you already tried the new version and provide some numbers regarding performance of this version?
No. I've mostly given up on the new version and reverted to the original. I'll come back to the new one in a few weeks probably.
Thanks for the purported fix though.