我经常遇到这样的情况:我想在声明查询的地方对查询进行求值。这通常是因为我需要对它进行多次迭代，计算成本很高。例如:
string raw = "...";
var lines = (from l in raw.Split('\n')
let ll = l.Trim()
where !string.IsNullOrEmpty(ll)
select ll).ToList();
这很好。但是如果我不打算修改结果，那么我也可以调用ToArray()而不是ToList()。
然而，我想知道ToArray()是否通过首先调用ToList()来实现，因此内存效率比只调用ToList()低。
我疯了吗?我是否应该调用ToArray() -在知道内存不会被分配两次的情况下安全可靠?
当前回答
一个很晚的答案，但我认为这对谷歌人有帮助。
They both suck when they created using linq. They both implement same code to resize buffer if necessary. ToArray internally uses a class to convert IEnumerable<> to array, by allocating an array of 4 elements. If that is not enough than it doubles the size by creating a new array double the size of current and copying current array to it. At the end it allocates a new array of count of your items. If your query returns 129 elements then ToArray will make 6 allocations and memory copy operations to create a 256 element array and than am another array of 129 to return. so much for memory efficiency.
ToList做同样的事情，但是它跳过了最后的分配，因为您可以在将来添加项。List不关心它是从linq查询创建的还是手动创建的。
List在内存上更好，但在cpu上更差，因为List是一个通用的解决方案，每个操作都需要范围检查，除了.net内部的数组范围检查之外。
因此，如果你将迭代你的结果集太多次，那么数组是很好的，因为它意味着比列表更少的范围检查，编译器通常优化数组的顺序访问。
如果在创建List时指定capacity参数，则它的初始化分配可以更好。在这种情况下，它将只分配数组一次，假设您知道结果大小。linq的ToList没有指定重载来提供它，因此我们必须创建扩展方法，该方法创建一个具有给定容量的列表，然后使用list <>. addrange。
为了完成这个问题，我必须写出下面的句子
At the end, you can use either an ToArray, or ToList, performance will not be so different ( see answer of @EMP ). You are using C#. If you need performance then do not worry about writing about high performance code, but worry about not writing bad performance code. Always target x64 for high performance code. AFAIK, x64 JIT is based on C++ compiler, and does some funny things like tail recursion optimizations. With 4.5 you can also enjoy the profile guided optimization and multi core JIT. At last, you can use async/await pattern to process it quicker.
其他回答
一个很晚的答案，但我认为这对谷歌人有帮助。
They both suck when they created using linq. They both implement same code to resize buffer if necessary. ToArray internally uses a class to convert IEnumerable<> to array, by allocating an array of 4 elements. If that is not enough than it doubles the size by creating a new array double the size of current and copying current array to it. At the end it allocates a new array of count of your items. If your query returns 129 elements then ToArray will make 6 allocations and memory copy operations to create a 256 element array and than am another array of 129 to return. so much for memory efficiency.
ToList做同样的事情，但是它跳过了最后的分配，因为您可以在将来添加项。List不关心它是从linq查询创建的还是手动创建的。
List在内存上更好，但在cpu上更差，因为List是一个通用的解决方案，每个操作都需要范围检查，除了.net内部的数组范围检查之外。
因此，如果你将迭代你的结果集太多次，那么数组是很好的，因为它意味着比列表更少的范围检查，编译器通常优化数组的顺序访问。
如果在创建List时指定capacity参数，则它的初始化分配可以更好。在这种情况下，它将只分配数组一次，假设您知道结果大小。linq的ToList没有指定重载来提供它，因此我们必须创建扩展方法，该方法创建一个具有给定容量的列表，然后使用list <>. addrange。
为了完成这个问题，我必须写出下面的句子
At the end, you can use either an ToArray, or ToList, performance will not be so different ( see answer of @EMP ). You are using C#. If you need performance then do not worry about writing about high performance code, but worry about not writing bad performance code. Always target x64 for high performance code. AFAIK, x64 JIT is based on C++ compiler, and does some funny things like tail recursion optimizations. With 4.5 you can also enjoy the profile guided optimization and multi core JIT. At last, you can use async/await pattern to process it quicker.
首选ToListAsync<T>()。
在实体框架6中，这两个方法最终都调用相同的内部方法，但ToArrayAsync<T>()在最后调用list.ToArray()，实现为
T[] array = new T[_size];
Array.Copy(_items, 0, array, 0, _size);
return array;
所以ToArrayAsync<T>()有一些开销，因此ToListAsync<T>()是首选。
这是一个老问题了——但是为了方便无意中发现它的用户，还有一种“Memoizing”Enumerable的替代方案——它具有缓存和停止Linq语句的多个枚举的效果，这就是ToArray()和ToList()经常被使用的原因，即使列表或数组的集合属性从未被使用。
Memoize在RX/System中可用。交互式库，并在这里解释: 更多LINQ与系统。互动
(摘自Bart De 's met的博客，如果你经常使用Linq to Objects，强烈推荐你阅读)
一种选择是添加自己的扩展方法，该方法返回一个只读的ICollection<T>。当您既不想使用数组/列表的索引属性，也不想从列表中添加/删除时，这可能比使用ToList或ToArray更好。
public static class EnumerableExtension
{
/// <summary>
/// Causes immediate evaluation of the linq but only if required.
/// As it returns a readonly ICollection, is better than using ToList or ToArray
/// when you do not want to use the indexing properties of an IList, or add to the collection.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="enumerable"></param>
/// <returns>Readonly collection</returns>
public static ICollection<T> Evaluate<T>(this IEnumerable<T> enumerable)
{
//if it's already a readonly collection, use it
var collection = enumerable as ICollection<T>;
if ((collection != null) && collection.IsReadOnly)
{
return collection;
}
//or make a new collection
return enumerable.ToList().AsReadOnly();
}
}
单元测试:
[TestClass]
public sealed class EvaluateLinqTests
{
[TestMethod]
public void EvalTest()
{
var list = new List<int> {1, 2, 3};
var linqResult = list.Select(i => i);
var linqResultEvaluated = list.Select(i => i).Evaluate();
list.Clear();
Assert.AreEqual(0, linqResult.Count());
//even though we have cleared the underlying list, the evaluated list does not change
Assert.AreEqual(3, linqResultEvaluated.Count());
}
[TestMethod]
public void DoesNotSaveCreatingListWhenHasListTest()
{
var list = new List<int> {1, 2, 3};
var linqResultEvaluated = list.Evaluate();
//list is not readonly, so we expect a new list
Assert.AreNotSame(list, linqResultEvaluated);
}
[TestMethod]
public void SavesCreatingListWhenHasReadonlyListTest()
{
var list = new List<int> {1, 2, 3}.AsReadOnly();
var linqResultEvaluated = list.Evaluate();
//list is readonly, so we don't expect a new list
Assert.AreSame(list, linqResultEvaluated);
}
[TestMethod]
public void SavesCreatingListWhenHasArrayTest()
{
var list = new[] {1, 2, 3};
var linqResultEvaluated = list.Evaluate();
//arrays are readonly (wrt ICollection<T> interface), so we don't expect a new object
Assert.AreSame(list, linqResultEvaluated);
}
[TestMethod]
[ExpectedException(typeof (NotSupportedException))]
public void CantAddToResultTest()
{
var list = new List<int> {1, 2, 3};
var linqResultEvaluated = list.Evaluate();
Assert.AreNotSame(list, linqResultEvaluated);
linqResultEvaluated.Add(4);
}
[TestMethod]
[ExpectedException(typeof (NotSupportedException))]
public void CantRemoveFromResultTest()
{
var list = new List<int> {1, 2, 3};
var linqResultEvaluated = list.Evaluate();
Assert.AreNotSame(list, linqResultEvaluated);
linqResultEvaluated.Remove(1);
}
}
我发现人们在这里做的其他基准测试都有不足，所以这里是我的尝试。如果你发现我的方法有问题，请告诉我。
/* This is a benchmarking template I use in LINQPad when I want to do a
* quick performance test. Just give it a couple of actions to test and
* it will give you a pretty good idea of how long they take compared
* to one another. It's not perfect: You can expect a 3% error margin
* under ideal circumstances. But if you're not going to improve
* performance by more than 3%, you probably don't care anyway.*/
void Main()
{
// Enter setup code here
var values = Enumerable.Range(1, 100000)
.Select(i => i.ToString())
.ToArray()
.Select(i => i);
values.GetType().Dump();
var actions = new[]
{
new TimedAction("ToList", () =>
{
values.ToList();
}),
new TimedAction("ToArray", () =>
{
values.ToArray();
}),
new TimedAction("Control", () =>
{
foreach (var element in values)
{
// do nothing
}
}),
// Add tests as desired
};
const int TimesToRun = 1000; // Tweak this as necessary
TimeActions(TimesToRun, actions);
}
#region timer helper methods
// Define other methods and classes here
public void TimeActions(int iterations, params TimedAction[] actions)
{
Stopwatch s = new Stopwatch();
int length = actions.Length;
var results = new ActionResult[actions.Length];
// Perform the actions in their initial order.
for (int i = 0; i < length; i++)
{
var action = actions[i];
var result = results[i] = new ActionResult { Message = action.Message };
// Do a dry run to get things ramped up/cached
result.DryRun1 = s.Time(action.Action, 10);
result.FullRun1 = s.Time(action.Action, iterations);
}
// Perform the actions in reverse order.
for (int i = length - 1; i >= 0; i--)
{
var action = actions[i];
var result = results[i];
// Do a dry run to get things ramped up/cached
result.DryRun2 = s.Time(action.Action, 10);
result.FullRun2 = s.Time(action.Action, iterations);
}
results.Dump();
}
public class ActionResult
{
public string Message { get; set; }
public double DryRun1 { get; set; }
public double DryRun2 { get; set; }
public double FullRun1 { get; set; }
public double FullRun2 { get; set; }
}
public class TimedAction
{
public TimedAction(string message, Action action)
{
Message = message;
Action = action;
}
public string Message { get; private set; }
public Action Action { get; private set; }
}
public static class StopwatchExtensions
{
public static double Time(this Stopwatch sw, Action action, int iterations)
{
sw.Restart();
for (int i = 0; i < iterations; i++)
{
action();
}
sw.Stop();
return sw.Elapsed.TotalMilliseconds;
}
}
#endregion
你可以在这里下载LINQPad脚本。
结果:
调整上面的代码，你会发现:
当处理较小的数组时，差异就不那么显著了。 在处理整型而不是字符串时，这种差异不太显著。 使用大型结构体而不是字符串通常会花费更多的时间，但并不会真正改变比例。
这与投票最多的答案的结论一致:
除非您的代码经常生成许多大型数据列表，否则不太可能注意到性能上的差异。(当创建1000个包含100K字符串的列表时，只有200ms的差异。) ToList()始终运行得更快，如果不打算长时间保留结果，那么它是一个更好的选择。
更新
@JonHanna指出，根据Select的实现，ToList()或ToArray()实现可以提前预测结果集合的大小。将上面代码中的. select (i => i)替换为Where(i => true)会产生非常相似的结果，并且更有可能这样做，而不管. net实现如何。
