我经常遇到这样的情况:我想在声明查询的地方对查询进行求值。这通常是因为我需要对它进行多次迭代，计算成本很高。例如:
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() -在知道内存不会被分配两次的情况下安全可靠?
当前回答
我发现人们在这里做的其他基准测试都有不足，所以这里是我的尝试。如果你发现我的方法有问题，请告诉我。
/* 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实现如何。
其他回答
内存总是会被分配两次——或者类似的情况。由于不能调整数组的大小，这两种方法都将使用某种机制在不断增长的集合中收集数据。(好吧，这个名单本身就是一个不断增长的集合。)
List使用数组作为内部存储，并在需要时将容量增加一倍。这意味着平均2/3的项目至少被重新分配过一次，其中一半至少被重新分配过两次，一半至少被重新分配过三次，以此类推。这意味着每个项目平均被重新分配了1.3次，这并不是很大的开销。
还要记住，如果你在收集字符串，集合本身只包含对字符串的引用，字符串本身不会被重新分配。
一种选择是添加自己的扩展方法，该方法返回一个只读的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实现如何。
除非您只是需要一个数组来满足其他约束，否则您应该使用ToList。在大多数情况下，ToArray会比ToList分配更多的内存。
两者都使用数组进行存储，但是ToList有一个更灵活的约束。它需要数组至少与集合中的元素数量一样大。如果数组更大，这不是问题。但是ToArray需要数组的大小精确到元素的数量。
为了满足这个约束，ToArray通常比ToList多做一次分配。一旦它有了一个足够大的数组，它就会分配一个完全正确大小的数组，并将元素复制回该数组中。唯一可以避免这种情况的情况是当数组的增长算法恰好与需要存储的元素数量一致时(绝对是少数)。
EDIT
有几个人问我在List<T>值中有额外的未使用内存的后果。
这是一个合理的担忧。如果创建的集合寿命很长，在创建后从未被修改过，并且有很高的机会落在Gen2堆中，那么您可能会更好地预先分配额外的ToArray。
总的来说，我发现这种情况比较罕见。更常见的情况是，大量ToArray调用被立即传递给其他短期内存使用，在这种情况下，ToList显然更好。
这里的关键是分析，分析，再分析更多。
我知道这是一个老帖子，但在有了同样的问题和做了一些研究之后，我发现了一些有趣的东西，可能值得分享。
首先，我同意@mquander和他的回答。在性能方面，两者是相同的。
但是，我一直在使用Reflector查看System.Linq.Enumerable扩展名称空间中的方法，并注意到一个非常常见的优化。 只要可能，IEnumerable<T>源就转换为IList<T>或ICollection<T>来优化方法。例如，查看ElementAt(int)。
有趣的是，微软选择只优化IList<T>，而不是IList。微软似乎更喜欢使用IList<T>接口。
