I'm pretty sure the real performance culprit comes from compiling new Regex instances over and over on each iteration, not from IEnumerable inefficiencies (i assume you meant that?). Compiled Regex'es are (usually) faster than interpreted, but take a while to actually compile, so instantiations should be done once (like on startup).

using System;
using System.Linq;

class TestClass
{
    public TestClass(int idx)
        => Console.WriteLine($"Instantiated new class: {idx}");
}

class Program
{
    static void Main(string[] args)
    {
        var range = Enumerable.Range(0, 10).Select(x => new TestClass(x));
        range.Any(_ => false);
        range.Any(_ => false);
        range.Any(_ => false);
    }
}

Good job on spotting the issue though; i was beginning to have concerns regarding slskd's CPU usage with barely any activity

These have always been compiled once when the app starts (or when options change):

The only real difference was the .ToArray(). I think there may be a nuanced issue with using IEnumerable<Regex> for the property type but I didn't test changing just that.

Garbage collection pressure increased along with CPU, which makes me think there's some sort of synchronous collection going on along with the state machine lifecycle under the hood.

The only real difference was the .ToArray().

IEnumerable produced by LINQ has deferred evaluation; it won't actually execute the expression until something forces it to materialize (.Any(), .ToList(), etc.). So, because CompiledSearchResponseFilters was storing an unmaterialized IEnumerable, each time something iterated over it (like calling .Any()), it was creating its' contents anew. And each time it did that, it was applying the .Select(f => new Regex(f, regexOptions)), thus recompiling all the regexes, which is slow

Just for demonstration purposes, you can try undoing the changes and then also get rid of the .Compiled flag. It should be faster, since it's not recompiling Regex anymore.

That's right, I forgot about that. I was just looking for similar optimizations in Soulseek.NET and was seeing .ToList() everywhere inside of constructors, so I knew this at one point :)