Article: SharePoint Object Model Performance Considerations

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?

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

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.

[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 :)

"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.)

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...

Good Case Study - thanks for the link

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?

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