# New filter is about x6 slower than old
**URL:** https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942
**Category:** General Discussion
**Created:** [February 21, 2010, 2:59pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942 "2010-02-21T14:59:25Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [February 21, 2010, 2:59pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/1 "2010-02-21T14:59:25Z")
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.
---
### Author:  [@dano](https://community.mp3tag.de/u/dano)
#### Post date: [February 21, 2010, 3:26pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/2 "2010-02-21T15:26:34Z")
I think you can speed it up greatly with
- HAS 00008637209025 OR \* HAS 00008637211721 OR \* HAS 00008637215521 ...
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [February 21, 2010, 4:17pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/3 "2010-02-21T16:17:15Z")
Thanks - good discovery! That speeds it to 50sec.
Florian, could you please implement this in the app?
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 21, 2010, 7:21pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/4 "2010-02-21T19:21:04Z")
> [@chrisjj](#):
>
> Florian, could you please implement this in the app?
You mean whether there is an non-regex equivalent of an arbitrarily complex regular expression? Seriously not.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [February 21, 2010, 7:36pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/5 "2010-02-21T19:36:15Z")
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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 21, 2010, 7:48pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/6 "2010-02-21T19:48:06Z")
\* 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.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [February 21, 2010, 8:36pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/7 "2010-02-21T20:36:13Z")
> \* 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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 22, 2010, 7:47pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/8 "2010-02-22T19:47:46Z")
> [@chrisjj](#):
>
> Understood and indeed that is not as slow (3min40s) but is still much slower than before.
This is indeed weird. I'll have a look at it and optimize it for the next version.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [February 22, 2010, 8:30pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/9 "2010-02-22T20:30:17Z")
> [@Florian](#):
>
> This is indeed weird. I'll have a look at it and optimize it for the next version.
I really hope you can prioritise the 6x speed loss Florian, since that is the far more serious one.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 27, 2010, 1:16pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/10 "2010-02-27T13:16:46Z")
This is now fixed with [Mp3tag v2.45c](http://developer.mp3tag.de).
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 3, 2010, 7:16pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/11 "2010-03-03T19:16:38Z")
Just curious: have you already tried the new version and provide some numbers regarding performance of this version?
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [March 3, 2010, 8:34pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/12 "2010-03-03T20:34:21Z")
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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 5, 2022, 8:36pm UTC](https://community.mp3tag.de/t/new-filter-is-about-x6-slower-than-old/9942/13 "2022-04-05T20:36:15Z")