perf: manually iterate OfType

[TimothyMakkison]

Manually iterate collection to avoid allocating OfType

Before

After

[Rekkonnect]

Is the outlined allocation issue because of OfType<T>? If that's the case, we could replace its usage across the board with a custom extension like OfTypeSlim<T>, without forcing using a loop in these cases. It should be self-contained and could be defined in any of these ways (haven't run benchmarks yet):

// Implementation A
public static IEnumerable<TUp> OfTypeSlim<TUp>(this IEnumerable source)
{
    return source
        .Cast<object>()
        .Where(static s => s is TUp)
        .Cast<TUp>();
}

// Implementation B
public static IEnumerable<TUp> OfTypeSlim<TUp>(this IEnumerable source)
{
    foreach (var value in source)
    {
        if (value is TUp up)
            yield return up;
    }
}

I highly doubt the performance will be still very bad after these changes

[thomhurst]

I think there's quite a lot of places where we want to check for certain attributes, and so iterate through them all to find one.

I was thinking of a new custom class for well-known types (I*EventReceiver, IClassConstructor, ITestExecutor, etc.).

When tests are first constructed/discovered, do a one-time iteration over the attributes. For each attribute, check if it is a certain type and store it as a property in our custom class.

Should make lots of enumerations and lookups redundant then.

[TimothyMakkison]

If that's the case, we could replace its usage across the board with a custom extension like OfTypeSlim, without forcing using a loop in these cases. It should be self-contained and could be defined in any of these ways (haven't run benchmarks yet):

I suspect this would be pretty much the same or worse as the compiler will still have to create a state machine iterator. I modified your code slightly so it will compile, but this is what it looks like.

The beauty of IEnumerable is it lets you chain together methods and defer execution. Unfortunately this means that you need to create an object to hold this logic hence the state machine creation. See the offical OfType implementation here'

[TimothyMakkison]

I think there's quite a lot of places where we want to check for certain attributes, and so iterate through them all to find one.

I was thinking of a new custom class for well-known types (I*EventReceiver, IClassConstructor, ITestExecutor, etc.).

When tests are first constructed/discovered, do a one-time iteration over the attributes. For each attribute, check if it is a certain type and store it as a property in our custom class.

Should make lots of enumerations and lookups redundant then.

Might be worth looking at, I do wonder how beneficial this will be as most methods only have 1 or 2 attribtues on them and iterating them is pretty fast, garbage non with standing.

[Rekkonnect]

It seems that the biggest offender is the definite allocation even in cases where the attribute isn't present, i.e. SkipAttribute being sought with OfType<> but never existing in any of the e.g. 500 methods the project has, thus resulting in this memory profile

[thomhurst]

Might be worth looking at, I do wonder how beneficial this will be as most methods only have 1 or 2 attribtues on them and iterating them is pretty fast, garbage non with standing.

Well if we're iterating anyway, this just moves it to one time in theory, and eliminates all of these further .OfType<> checks/eliminations that we're doing now I guess!

[TimothyMakkison]

FWIW most OfType allocations won't really be a concern after this and most of the Enumerator / Enumerable objects are dwarfed by the size of the Concurent enumerators. TBH this was more of a procrastination PR because I'm trying to avoid doing the more impactful annoying stuff. I don't think O(n) is massively relevant here because of the tiny sizes of the collections

Current OfType iterators (PropertyBag is a different library)

For reference 17.1K tests allocate 1.05GB of objects

All Enumera types