1

我有一个应用程序，它可能在每个微积分中使用大量数据。

我有一个包含很多属性的“A 类”。我有大约 10k 这个类的对象。

  • 所以我的想法是只从数据库中加载一次并使用它们进行搜索。

所以我创建了一个 List ：

public static List<ClassA>

在我的应用程序中。

经过一些测试，它确实比每次从数据库中加载我的数据都要快。

但我认为这不是一个好方法吗？垃圾收集器呢？它会被这个庞大的数据列表所困扰吗？

  • 我的第二个想法是将我的 Class1 分成不同的类，以便从数据库中获得更小的请求。我的代码肯定更干净。但是现在真的很慢。

我在 List 方法中看到的唯一大问题是我的 Data 的持久性：我必须修改 List 中的元素（因此在列表中搜索它们）并通过 EntityFramework 持久化它们，而不是从 EF 中获取它们，然后修改它们通过 EF 持久化它们。

当然，避免使用该列表似乎“更好”，但是如果我不使用它，性能会很差。

  • 我将探查器与列表一起使用，创建列表需要花费大量时间（每次我搜索某些内容时，它都会返回一个较小的列表：例如，获取属性“名称”等于“blabla”的所有对象）
4

2 回答 2

1

当然，避免使用该列表似乎“更好”，但是如果我不使用它，性能会很差。

这是一个非常常见的权衡：您为 CPU 周期和网络带宽支付内存。如果您认为列表永远留在内存中是一件坏事（静态列表肯定会，直到您明确清除它），您可以创建一个“缓存”对象，将您的列表存储在其中，并仅保留它只要需要。一旦你完成了列表，摆脱你的“缓存”对象，你的列表就会被垃圾收集。

于 2013-09-06T02:15:54.933 回答
0

哇...好吧，没有对整个应用程序的明确解释，我在这里看到了一些危险信号。

首先...我在这里主要关心的是您说您已经完成了基准测试并表明将整个数据库加载到您的应用程序中比在每个数据库调用中临时重新水化每个对象更快。

我需要知道你是如何进行基准测试的，才能知道你的假设是否正确。

原因如下。

在 EF 上，查询的主要成本是数据库的延迟、结果集到对象的绑定以及查询的编译。

在您的静态列表中，主要成本是遍历庞大的数据集以找到正确的项目、线程错误以及很可能会导致内存碎片的 LOH 中的对象。

对于少量对象，将对象绑定到数据读取器的成本应该很小，但（一次性）编译成本很大。假设一个调整良好的数据库，查询应该命中索引，这应该使数据库服务器上的 I/O 成本很小。

虽然针对大型静态列表的类似查询将在很大程度上得到优化（除非您编写某种索引代码，例如某种关系数据结构）。

最后，在没有看到您如何构建代码的情况下，很难理解如何更快地将整个数据库加载到您的应用程序中以提高速度。

您能否展示一些代码清单，说明您实际使用 EF 的方式、所涉及的类、您正在运行的 .net 框架版本等...

于 2013-09-06T03:59:40.793 回答