Using SPList.ItemCount vs SPList.Items.Count

Developers need to write code that doesn’t consume all the server resources, so they try to use the best API calls that require minimum resources. Many feel that when it comes to using SPList.ItemCount versus SPList.Items.Count, SPList.ItemCount is a better API call. But let’s examine this more carefully.

What are the Definitions?

The MSDN definitions for both scenarios are as follows:

SPList.ItemCount: The value of the ItemCount property includes folders within a document library, as well as files within subfolders. The value of the Count property of the SPListCollection class doesn’t include folders.

SPList.Items.Count: The Items property returns all the files in a document library, including files in subfolders, but not the folders themselves. In a document library, folders aren’t considered items.

Therefore we can conclude that SPList.Items.Count gets the number of list items in the collection, excluding folders.

What Happens Behind the Scenes?

If we compare what happens behind the scenes, SPList.ItemCount gives the count of all the items in the particular list. On the other hand, SPList.Items.Count gives the count of the items that are returned based on a query executed. Therefore the resources required for SPList.Items.Count are much higher than for SPList.ItemCount, so we can assume that SPList.ItemCount is the best code for execution.

What are the Concerns?

Imagine a situation where there are checked-out items. Also consider a list with folders. A document library is the best example.

List.ItemCount

List.ItemCount brings the checked-out items in the list as well. (A folder available inside a list is considered an item.) The ItemCount property value doesn’t always mean it’s the list item count. Also I found in some places that the items dumped into the recycle bin also get counted in as items because SharePoint lists do a soft delete when items are sent into the recycle bin. Physically, the deleted item is still inside the list with a flag as deleted.

Another important fact about ItemCount property is that it isn’t always up to date. To improve the performance of the code, SharePoint keeps a cache of the value rather than counting all items every time this code is executed.

List.Items.Count

On the other hand, the List.Items property is security trimmed. Which means each user will see the items that are shared only with the browsing user. This excludes the number of folders in the list. But every time this property is called, it executes a query and gets the latest up-to-date count of the items accessible by the current user.

Is List.ItemCount Always Greater Than or Equal to List.Items.Count?

I believe so, because there’s no reason that List.ItemCount could be lower. But there are some very rare situations that have been reported proving the contrary, in some forums. The assumption is that List.ItemCount isn’t always up to date, so it might take a little while to update.

Best Practices

With concerns such as running queries on database with SPList.Items.Count as opposed to the accuracy of the output value SPList.ItemCount, I wouldn’t say there is always a best practice. If your list/ library doesn’t have checkout and publishing options and folders, it’s better to go with the List.ItemCount. This will mostly be used for a simple check where you’re not hugely concerned about the exact numerical value.

In a situation where there are a large number of items present, List.ItemCount would be a good option to get an idea about the number of items available, as it doesn’t require running a query to get the count.

But in a situation where you need to get the last item of a list, getting the last index will be better with the List.Items.Count. For example:

Bad:

SPListItem lastItem = list.Items[list.ItemCount -1];

Good:

SPListItem lastItem = list.Items[list.Items.Count -1];