C# - 使用字符串属性重用对象与创建新实例的性能答案

【问题标题】：C# - Performance of reusing object with string properties vs creating new instanceC# - 使用字符串属性重用对象与创建新实例的性能
【发布时间】：2016-01-31 14:09:21
【问题描述】：

假设我有包含 3 个字符串属性的 A 类。在整个应用程序中不必要地创建了 A 的新实例数次。 A 类所做的就是使用这 3 个字符串来执行 LINQ 查询，例如：

Where(string1 == this.string1).Where(string2 == this.string2).Where(string3 == this.string3)

我不是在每次需要对象时都创建一个实例，而是考虑修改使用这种类型的类来存储对象的一个实例，然后在每次使用它之前修改字符串属性。这是优化课程的正确方法吗？基本上，我试图避免每次创建实例和为字符串分配内存的开销。

是否有更快的方法来执行上述 LINQ 查询？

【问题讨论】：

您需要编写两个选项并测量性能。
“包含”三个字符串的类很小，因为字符串本身并不“包含”。您需要了解类是如何存储的，字符串是如何存储的，您需要了解字符串实习，您需要了解垃圾收集以及 GC0、1 和 2 的成本。然后也许您将准备好考虑优化这个类。
创建不同的字符串很可能比创建您的持有实例更昂贵。也就是说，除非字符串很大，否则这听起来像是过早的优化。不要试图猜测性能问题。衡量然后优化。

标签： c# string performance

【解决方案1】：

是的。但除非有很多这样的对象，否则性能上的差异可以忽略不计。

【讨论】：

你怎么知道它可以忽略不计？
你怎么知道new 一个A 的实例需要多长时间？ OP 的对象池性能如何？
@Enigmativity，OP 可能意味着平均 A 类，它有 5-10 个字段，因为他已经清除了。为此，我写的是真的。
我不是说你错了，但你不知道 OP 的实际实现是什么，他的类 A 以及他将使用什么池代码。在我们知道这一点并实际测量差异之前，我们无法确定结果。我怀疑你是对的，但我们只是不知道。

【解决方案2】：

如果“几次”大约是几千次，那么我不会担心创建对象的性能。仅当您创建的对象太多以至于应用程序不得不频繁执行垃圾收集来清理未使用的对象时，对于具有 3 个属性的对象，除非您的字符串非常大，否则这些对象需要达到数百万的数量级。

您更有可能通过尝试重用对象来创建错误，因为您冒着忘记在重用之间清理对象状态的风险。

尝试重用对象可能意味着将其移动到比必要的更高级别的范围。 IE。更改对属性或类似的本地引用。

保持代码简单，而不是实施过早的优化，这样当您确实遇到优化非常重要的情况时，您可以更轻松地实施优化。如果你过度优化你能想象到的一切，那么你最终会得到一个过于复杂的代码库。

更新：

我正在考虑修改使用这种类型来存储的类对象的一个实例，然后修改字符串属性每次使用之前。这是优化的正确方法吗上课？

您在内存分配领域并没有节省太多。由于您每次都在分配新字符串，因此大部分分配是在字符串的创建中，而不是在对象的创建中。

外部对象仅包含 3 个指针。

无论你是否重复重用同一个对象，大部分内存分配都是每次创建字符串。

如果您要努力优化，您的努力应该集中在最有益的地方。致力于优化的工作应该从分析开始，以确定你的慢点在哪里。这意味着优化那些被测量为问题区域的东西。

【讨论】：

是否有另一种不会使代码过于复杂的优化方法？
@Andrew 在不知道您的应用程序结构的情况下，我猜答案是否定的。过早优化的问题在于您正在优化已经非常有效的东西。在编译器和垃圾收集器之间，涉及到许多非常先进的算法来优化代码和内存。您所做的任何事情都不太可能显着提高性能，除非您处于一个非常具体的场景中，您发现了一个明显的性能问题。
这有点像用砂纸打磨镜子。镜子已经很光滑了，你不可能用粗砂纸把它磨得更光滑，而且可能会变得更糟。
我读过关于字符串实习的文章，听起来很多这些字符串无论如何都缓存在字符串实习池中。基本上，A 类所做的是使用这 3 个字符串来执行 LINQ 查询，例如“Where.(String1==this.String1) && (String2 == this.String2) && (String3 == this.String3)。我不'没有正确的语法。我想知道我是否可以优化 LINQ 查询（使用实体框架）？
现在我们讨论的是优化 LINQ 查询而不是优化内存访问。我建议创建一个新问题并包含比 sn-p 更多的代码，以便更清楚您正在使用这些数据做什么以及完整的查询是什么样的。