Performance MFC CListrCtrl:批量更新虚拟列表数据

有没有一种方法，可以通过CListCtrl本机支持，或者通过某种编码技术，以虚拟列表模式CListCtrl而不是一次更新一块数据

默认情况下，当列表需要单元格的数据时，我们通过LVS_GETDISPINFO处理它。如果说8x8（64）个单元格可见并不断更新，那么它基本上是将处理程序调用LVS_GETDISPINFO 64次。这是一个很好的预期行为，但我相信重复调用此函数会有很小的开销，而不是在所有64个单元的for循环中进行。这对我来说是个问题，因为我的控件不断更新所有64个单元格（想象一下TCP数据包跟踪之类的东西）

CListCtrl当然支持缓存（虽然在我的情况下没有用处），但我还是觉得反复调用LVS_GETDISPINFO处理程序会带来开销。一个简单的例子是，在获取数据之前确定我指向数据库的指针是否有效（非空）。。。实际上，这行代码被调用了64次，而我本可以只调用一次，然后for循环指针以获取我的64个单元格的数据。另外，指针只是一个简单的例子，我正在做的事情（无法避免）还有很多，我不会解释，因为它需要代码

由于时间至关重要，我不能回去重新编写我自己的更高效的列表ctrl，因为复制CListCtrl的其他好处需要时间，而我正通过直接继承它来享受这些好处。现在唯一的问题是速度。如果有一种方法，比如一个处理程序，它传入一个以null结尾的单元格数组进行更新，这样我们就可以在一个函数中批量更新它，那就太好了

或者，是否可能知道LVS_GETDISPINFO中哪些单元格正在等待更新，以便在可能的情况下更新所有单元格，并验证整个更新以停止获取LVS_GETDISPINFO

---

有什么想法吗？提前感谢。

也许您可以使用SetRedraw（FALSE）而不是填写列表并调用SetRedraw（TRUE）一次显示所有结果。但是，很难证明性能受到的影响是合理的，因为默认列表确实为您提供了一个干净的实现。如果你想做批量的事情，你会增加更复杂的行和列的变化，这将很难维护和照顾。是的，我正在使用SetRedraw方法来消除闪烁。嗯，我希望批量方法只在需要“完全可见区域”更新时才使用（这在我的案例中基本上一直是正确的，因为它不断更新所有单元格），因此我们没有管理要更改的行和列的复杂性。或者换句话说，它将始终是一个连续的行范围。无论如何，我同意你的观点，默认值是最干净的实现。我猜CListCtrl不适合快速更新数据。在放弃之前，我会继续思考。