按类型划分Linq查询的性能

Question

A discussion has come up at work:

We've got a class that has an IList. Fact is an abstract base class, and there are several concrete subclasses (PopulationFact, GdpFact, etc).

Originally we'd query for a given fact in this fashion, ie by type:

.Facts.FirstOrDefault(x => x.Year == 2011 && x is GdpFact)

Now, however, the question's been raised whether we should introduce a FactType enum instead to do

.Facts.FirstOrDefault(x => x.Year == 2011 && x.FactType == FactType.Gdp)

The suggestion has been raised because it is supposedly faster. I'll admit that I've not written any tests to try and discern the difference in performance, but I have two questions:

1) Is 'querying on type' like this inherently bad?
2) Isn't adding a FactType enum just superfluous anyway, given that facts are strongly typed?

UPDATE To clarify, this is LINQ to objects and GdpFact:Fact.

UPDATE 2 We've measured using current typical data (4 facts) and the results are in:

lookup on enum: 0.29660000000000003 milliseconds lookup on type: 0.24530000000000002 milliseconds

So type lookup is faster in this context! I will choose my accepted answer carefully.

Answer 1

All type of preformance related questions are strictly dependent on concrete application context , so may be answer(s) provided here will be partially right/wrong for your concrete case .

Having this in mind:

Checking enum value should be reasonably faster then checking for type, as in first case, you just check for equality 2 integers (enum values).

But that introduce one more field in the object, that has to be tracked to have correct value (unit test), which you do not need in second case, as CLR cares about correct type initialization.

I think it's better that you profile your ideas against relevant amount of data, that your app usually operates over, and will come out with correct idea for you .

Answer 2

I've done a test, my results for 1000000 iterations are approximately

ByCast 166ms
ByType 84ms
ByEnum 98ms

So the enum is in fact superfluous and slower but, not by much. This should not be too suprising, the type system is fundamental to the .Net Framework.

Test code transcribed below, apologies for errata

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

class Program
{
    private enum TypeOfFact
    {
        Gdp,
        Other
    }

    private abstract class Fact
    {
        public virtual int Year { get; set; }
        public abstract TypeOfFact FactType { get; }
    }

    private class GdpFact : Fact
    {
        public override TypeOfFact FactType
        {
            get { return TypeOfFact.Gdp; }
        }
    }

    private class OtherFact : Fact
    {
        public override TypeOfFact FactType
        {
            get { return TypeOfFact.Other; }
        }
    }

    static void Main()
    {
        Ilist<Fact> facts = new List<Fact>
            {
                new GdpFact { Year = 2010 },
                new OtherFact { Year = 2010 },
                new GdpFact { Year = 2009 },
                new OtherFact { Year = 2009 },
                new GdpFact { Year = 2011 },
                new OtherFact { Year = 2011 },
            };

        const int interations = 1000000;

        var funcs = new List<Func<IList<Fact>, Fact>>
            {
                ByList,
                ByType,
                ByEnum
            };

        // Warmup
        foreach (var func in funcs)
        {
           Measure(5, func, facts);
        }

        // Results
        foreach (var result in funcs.Select(f => new
            {
                Description = f.Method.Name,
                Ms = Measure(iterations, f, facts)
            }))
        {
            Console.WriteLine(
                "{0} time = {1}ms",
                result.Description,
                result.Ms);
        }
    }

    private static long Measure(
        int iterations,
        Func<IList<Fact>, Fact> func,
        IList<Fact> facts)
    {
        var stopwatch = new Stopwatch();
        stopwatch.Start();
        for (var i = 0; i < iterations; i++)
        {
            func.Invoke(facts);
        }

        stopwatch.Stop();
        return stopwatch.ElapsedMilliseconds;
    }

    private static Fact ByType(IList<Fact> facts)
    {
        return facts.FirstOrDefault(f =>
            f.Year == 2011 && f is GdpFact);
    }

    private static Fact ByEnum(IList<Fact> facts)
    {
        return facts.FirstOrDefault(f =>
            f.Year == 2011 && f.FactType == TypeOfFact.Gdp);
    }

    private static Fact ByCast(IList<Fact> facts)
    {
        return facts.OfType<GdpFact>()
            .FirstOrDefault(f => f.Year == 2011);
    }
}

---

This question seems relevant.

Answer 3

Is this maybe a solution looking for a problem?

I think having both concrete subtypes and an enum in the base type could potentially obfuscate your design. You could imagine someone coming along later and writing a new concrete class but not realising they needed to add to the enum as well...

Unless you find you have a specific problem to do with performance, I'd be tempted to prioritise clarity instead. Therefore if you need different concrete classes (and I'm assuming you do since that's how you've coded it to start with) then I'd stick with your types rather than move to an enum.

Answer 4

I think your original approach is fine. the 'is' keyword is provided for this purpose. MSDN does not discourage the use of 'is'. Using an enum seems to be over-engineering. We should try and keep code simple. Fewer the lines of code the better it is in most situations.

Answer 5

It's possible that checking an enum value will be faster than a runtime type-check, but...

1. It's a micro-optimisation -- you're unlikely to notice much perf difference in real-world scenarios.

2. It makes things more complicated, and more complicated means more likely to break.
   For example, what's to stop you, or one of your colleagues, accidentally doing something like this?

    public class PopulationFact : Fact { public FactType FactType = FactType.GdpFact; // should be PopulationFact } 

I'd stick with the type-check. There's actually a built-in LINQ method that'll do it for you:

.Facts.FirstOrDefault(x => x.Year == 2011).OfType<GdpFact>()