数据读取器 - 返回可枚举/可查询是否比返回列表的性能更高
本文关键字：返回 列表 性能 是否 读取 枚举 数据 查询 | 更新日期: 2023-09-27 18:36:06
如果数据读取器在接收数据时释放数据，则使用枚举应允许该数据立即从数据访问函数发送回调用方。
如果我使用基于列表的方法，那么调用方将等待接收所有数据，因为必须"枚举"整个读取器才能转换为列表。
这种理解是否正确，因此在使用数据读取器编写数据访问代码时，避免使用列表返回集合通常更快？
我的意思是可能使用读取器在数据访问函数中使用收益返回，而不是初始化对象列表并将对象添加到然后返回的列表。
错。由于延迟计算，它不仅是即时的，而且还可以防止不必要的内存分配，因为您一次只处理一行。
最好将大量数据保留在数据库中。
取决于你所说的更快是什么意思
我将其视为批量与端到端。
例如，如果要在读取器中显示为该行创建的实例。然后返回 IEnumerable 会给你一个机会，并且没有等待您枚举的所有实例创建的不幸的口吃。
另一个问题是您要返回的任何内容的生命周期。如果它在处理后立即超出范围，那么 IEnumerable 就是要走的路，因为 List 意味着为所有这些分配内存，其中 IEnumerable 一次足以容纳一个内存。
另一个问题是处理其中一个枚举项目需要多长时间，从来没有让读者保持开放相当长的时间，我一直坚信客户与数据库的交互速度小而快。
所以我的说法通常是正确的。
这是您正在谈论的 2 个不同概念; 一个需要在连接模式下工作（流式处理方法，它将尽快返回结果），而另一个将获取结果并释放连接。 我不认为更快在这里是一个准确的术语。如果你有 N 条记录，它们不会更快地到达客户端，尤其是在需要任何附加计算的情况下。客户端可能会更快地看到一些结果，但可能不会看到整个列表（这是在每个特定情况下都可以轻松测量的），并且您必须从代码中支付额外的性能，以使调用方与结果保持同步（类似于并发集合）。
例如，在Web环境中，这是可以做到的，但代码编写/管理和同步的成本非常高，我认为在大多数情况下，这不值得付出努力。