Article: SharePoint Object Model Performance Considerations

| by Abel Avram Follow 11 Followers on Mar 04, 2009. Estimated reading time: less than one minute |

In this article, Andreas Grabner analyzes the performance implication of using the SharePoint Object Model, specifically displaying and editing lists, one of the most used SharePoint objects.

Read: SharePoint Object Model Performance Considerations

The article focuses on SharePoint lists. There are many list usage approaches described by the SharePoint documentation, but not all are recommended for any scenario. Grabner advices the readers on how to avoid the performance pitfalls associated to improper use of lists by giving problematic code samples and their corresponding recommended ones.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Screenshots by Francois Ward

Nice article. Honestly though, most of these things would be obvious if the Sharepoint object model followed the .NET Framework Design Guidelines... the fact that accessing a public property causes so much side effects and is so performance intensive (like the .Items property) is a pitfall that is warned about over and over. People WILL use public properties in loops, and during a code review it isn't obvious.

If that was not available, and only GetItems was, it would be obvious to most seasoned developers that performance impacts may be involved and to not use it repeatedly.

Anyway...the performance screenshots displayed in the first part of the article... are they from dynaTrace too, or another tool?

Re: Screenshots by Andreas Grabner

All screenshots are from dynaTrace
You can also read more about my SharePoint findings on my blog: or

Re: Screenshots by Stefan Wenig

If done right, SP would be built on top of an O/R mapper. It could then just cache those lists internally and return them the next time you'd access the property. But things being what they are, you're right, it should definately be GetItems(), or rather LoadItems() to be really explicit about what happens.

Btw, I guess you can tell it's dynaTrace just from the fact that it lets you drill down into method parameters. This really gives you answers where other tools just provide hints for further research.

Re: Screenshots by Francois Ward

[blockquote]If done right, SP would be built on top of an O/R mapper[/blockquote]

OR/M or not, they could still be cached internally, thats not an issue. It could still be done, but it would have to be optional...some lists can be far too large (Ive seen sites with thousands of lists of hundreds of thousands of items...), so it couldn't be an "always" thing, it would have to be optional, and then things would get complicated.

Just following the .NET framework design guidelines, so that things in SP behave like they do in everything else would be more than sufficient, honestly. Not just for performance, but for development efficiency, and even for SP's developers themselves, it would be a decent bit easier.

Oh well! Until then, there's posts like these to enlighten us small folks :)

Re: Screenshots by Stefan Wenig

"they could still be cached internally"

yes, but since SharePoint has no concept of transactional behavior, that would mean that the cache might not be up to date with the information in the data store. One way to solve this is to leave all caching to the application developer, like they do now - only then it would have to be named GetItems() like you already said. This is pretty hard to get right on an app by app basis, but at least then it's not SP's fault ;-)

Another way would be to have a sensible concept of caching and cache invalidation, which is something that O/R mappers usually have. (Of course, these concepts could be implemented in SP without an O/R mapper, it just makes little sense to do that.)

useful recommendations by Dana Miller

There are some good recommendations in there. We followed a lot of those, but still ran into problems. We solved some of them after reading this:

Re: useful recommendations by Andreas Grabner

Good Case Study - thanks for the link

Loop efficiency by Nick Tulett

In Case 2, wouldn't it be better to cache the List Items' count as a simple integer before the loop, saving yourself (in your example) half the time spent in the inner loop?

Re: Loop efficiency by Andreas Grabner

Caching the value would be one option. the best option however would be to use the ItemCount property which doesnt require a roundtrip to the database

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you