Запросы LINQ имеют много издержек?
Можно создать словарь от ряда длины 2 последовательности. Чрезвычайно удобный, когда у Вас есть список значений и список массивов.
>>> dict([ ('foo','bar'),('a',1),('b',2) ])
{'a': 1, 'b': 2, 'foo': 'bar'}
>>> names = ['Bob', 'Marie', 'Alice']
>>> ages = [23, 27, 36]
>>> dict(zip(names, ages))
{'Alice': 36, 'Bob': 23, 'Marie': 27}
6 ответов
Авторы LINQ in Action провели сравнительный анализ для, foreach, List и запросов LINQ, которые все сделали то же самое. В зависимости от того, как были построены запросы, LINQ был лишь примерно на 10% медленнее . По их словам,
LINQ не предоставляется бесплатно.
LINQ - сложная тема, но в зависимости от того, что вы с ним делаете, это не требует дополнительных затрат. Как правило, LINQ построен так, чтобы по возможности полагаться на отложенное выполнение, чтобы сэкономить память и процессор до тех пор, пока они вам действительно не понадобятся.
Однако вы должны знать, как работают разные операторы запроса, потому что изменение потока запроса может радикально изменить способ его выполнения. Простые запросы, как вы описываете, обычно не являются проблемой, но такие операторы, как Reverse () и операторы преобразования, могут вызвать некоторые затруднения, поскольку они требуют немедленной итерации набора результатов. Часто существует несколько способов написать один и тот же запрос, и в зависимости от того, как вы его построите , вы можете рассчитывать на минимальную потерю производительности или сделать его вдвое медленнее , чем у эквивалентные петли.
Однако удобство и лаконичность, которые он предлагает, намного перевешивают любые соображения производительности для большей части моего повседневного программирования. Никогда не выполняйте предварительную оптимизацию!
Вот мое общее правило для LINQ
Используйте LINQ, когда решение больше выразительный. Переходите к менее выразительному, но более быстрому решению только тогда, когда профилировщик доказал, что запрос LINQ является источником проблемы.
There's the overhead of invoking delegates, but that's generally fairly low.
Then there's the overhead of all the iterators involved - usually one iterator per extra clause in the query. Again, not a huge amount, but not nothing either.
Do you have an actual application in mind? If so, how important is the performance in the bit which could be done in LINQ? In my experience these bits are usually not the bottleneck, so if LINQ decreases the performance very slightly it really doesn't matter. LINQ can contribute greatly to the readability of your solution though.
Note that the performance in your example is quite different because the two pieces of code are doing very different things. Your LINQ example will execute in the blink of an eye because it's not actually running the query - it's just setting it up. If you call ToList() at the end then it's basically equivalent to your second example. This sort of thing is very important to remember when doing performance comparisons!
Another thing to bear in mind - you don't have to use the query expression syntax. If you're just filtering (or just projecting) I usually find it makes more sense to call the extension method with normal dot notation:
var lowNums = numbers.Where(n => n < 5);
About the only real performance overhead of LINQ-to-objects over doing it yourself are the few extra objects created to help with the enumeration and the function calls. In short, unless you use it in a way it wasn't designed to, it won't hurt your performance unless you're doing very high-perf stuff.
In that case, I'd implement it the LINQ way first, and let your performance testing tell you in which specific places you may need to consider doing it differently. For quite a bit of code, ease of maintenance trumps pure performance.
One great way to convince yourself about LINQ is to use LINQPad. It allows you to output the IL for your LINQ and non-LINQ implementations (as well as output the SQL if you're using LINQ2SQL).
Often times when I have a question about what is exactly happening "behind the scenes" (as your co-worker is wondering), I go to the IL and find out for myself. The vast majority of the time what I've seen is that LINQ's implmenetation is superb.
Согласно LINQ в действии (стр.198):
«LINQ не предоставляется бесплатно. LINQ запросы вызывают дополнительную работу, объект творения и давление на мусор коллекционер. Дополнительная стоимость использование LINQ может сильно отличаться в зависимости от запрос. Это может быть всего 5 процентов, но иногда может быть около 500 процентов. "