Be selective about how you get items from an SPList

Just read an interesting article from Waldek Mastykarz called ‘Performance of various methods to retrieve one list item’. It’s well worth a look – go and read it.

So, the interesting thing I took away from it was just how slow the GetItemById() method was compared to an SPQuery. Why? Wouldn’t it make sense to use and SPQuery within the GetItemById() method?

Well a bit of Reflector digging (again) shows that it does! But it isn’t just a query for the item with that Id – it also specifies that the

SPQuery.ViewAttributes = "Scope="RecursiveAll" ModerationType="Moderator" ";

Hmm. So it’s probably a more complicated query. Depending on your solution, you might not need “RecursiveAll” – I try to avoid folders in lists, preferring views to break down my content.

So, the lesson that I took away was that if you are doing a LOT of getting items from lists, it is worth considering how you want to. There isn’t a right answer, unfortunately, and testing is key. The problem is, there are many factors:

  • Can you use caching?
  • Do you know the list you’re getting items from?
  • Are you getting items from more than one list?
  • Do you have folders?
  • What other parameters might your query have?

It’s difficult to know, hence I think Waldek is right – give it a test so you have some idea!

Be selective about how you get items from an SPList

Interesting Idea for Efficiency – Avoid SPList.Items…

An interesting post by Rob Garrett about avoiding using SPList.Items.Add() – as referencing SPList.Items causes you to get all items in a list, and that can be pretty slow. He does suggest a solution.

I must confess, I’m surprised. I mean, what he describes makes sense – and also explains why have both SPList.ItemCount and SPList.Items.Count (same problem – and the former should be faster) – but surely there is some equivalent already build, some SPList.AddItem() to do it for you? Guess not.

Might be a small optimisation, but it starts to become clearer why the 2000 item recommendation…

At some point, I’ll try and generate some metrics, and then we’ll see when it becomes more efficient and how much so.

Interesting Idea for Efficiency – Avoid SPList.Items…

WSS Practice: Checking in/out Documents, and Versioning

Well, for the WSS application developer exam, you’re supposed to know about programmatically checking in and out documents:

//*** Check out a document
Console.WriteLine("Check out {0}", myItem["Name"]);
myItem.File.CheckOut();
Console.ReadLine();
//*** Check in a Document (Minor Check in)
myItem.File.CheckIn("Checked in Programmatically", SPCheckinType.MinorCheckIn );
Console.WriteLine("Item Checked in");
Console.ReadLine();

One should also be able to list all versions of a document:

//*** List all versions of a document
Console.WriteLine(myItem.Name);
foreach (SPFileVersion ver in myItem.File.Versions)
{
Console.WriteLine(" - v{0} ({1})", ver.VersionLabel, ver.CheckInComment);
}
Console.ReadLine();

And restore a version:

//*** Restore to version 1.0
myItem.File.CheckOut();
myItem.File.Versions.RestoreByLabel("1.0");
myItem.File.CheckIn("Restored by Program to v1.0");
Console.WriteLine("{0} restored to v1.0", myItem.Name);

All pretty straight forward.

WSS Practice: Checking in/out Documents, and Versioning