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.

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?

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

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