A look under the hood, using Reflector to explore Microsoft.SharePoint.dll

 

We've all used Reflector to open up a .NET assembly and look at the code. But did you ever think of doing this to the core SharePoint assemblies? I had never thought of it until last week at Sleepless in Dallas, Nadeem Mitha of Infusion suggested it. It is quite instructive, and reveals a couple very important nuances that if you don't understand can make your code very slow.  For example, looking at the SPList.Items property you can see that this property simply calls the GetItems() method to retrieve all items for that list. So here is the kicker, any time you call the Items property it is retrieving all the items in the SharePoint list, even if you just call the Items[0] , SharePoint retrieves all the items in a list and then peels off the first one and gives it to you, very inefficient.

Other classes to look at are  GetItemByUniqueId(Guid uniqueId). You can see that behind the scenes, Microsoft is creating a CAML query and retrieving items. Why Microsoft insists on throwing an exception when no results are found, is beyond me. A simple null would have sufficed, thank you very much!

 

I always thought the assemblies would have been obfuscated, but surprisingly, and to our benefit, they aren't. Hope this gives you some idea, but I think this is a great tip! It takes a lot of the mystery out of SharePoint, and also shows what the heck Microsoft was thinking.