I've got a ListView control that has over a million ListViewItems. Each ListViewItems contains two strings. I'm pulling all the registry entries for a Windows machine -- both the path + key name, and the data.
When I attempt to call ListView.CheckedItems.Count, it won't return as fast as I'm expecting it to (I've tested running it for days waiting for it to respond). At first I thought I was hitting some type of lock contention issue, however, when I lowered the number of entries in the control, the method would return. What's odd is that the time it takes to traverse the list seems to double for every 100,000 entries:
- 100,000 takes 00:45 to return.
- 200,000 takes 03:58 to return.
- 300,000 takes 09:31 to return.
- 400,000 takes 17:08 to return.
- 500,000 takes 26:56 to return.
Traversing through the items to see if it is "checked" or not shouldn't take this long, even with 500,000 entries, right? What could be going on and is there a workaround?
System info:
Windows 10 Enterprise 64-bit (Fully patched as of 9/11/2017) 32GB of Ram Visual Studio 2017 .NET Framework 4.6.1
The amount of ram used while running hovers around 5GB. CPU utilization is negligible -- looking at this program in Sysinternals ProcessExplorer shows that a single thread is running at around 12% while it calculates the value of the checked items count.
The application is a simple windows form. The delay happens if stepping through in debugger mode or if directly running the release built binary.
