BT

InfoQ Homepage News Article: SharePoint Object Model Performance Considerations

Article: SharePoint Object Model Performance Considerations

Bookmarks

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
Style

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.

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

Community comments

  • Screenshots

    by Francois Ward /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    All screenshots are from dynaTrace
    You can also read more about my SharePoint findings on my blog: blog.dynatrace.com or blog.dynatrace.com/tag/sharepoint-net

  • Re: Screenshots

    by Stefan Wenig /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    [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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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: www.webperformanceinc.com/library/casestudies/s...

  • Re: useful recommendations

    by Andreas Grabner /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Good Case Study - thanks for the link

  • Loop efficiency

    by Nick Tulett /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.