Article: SharePoint Object Model Performance Considerations
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.
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.
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?
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.
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.)
Daniel Jebaraj Mar 12, 2014
Evolving Culture and Values. Understanding the Tradeoffs. Growth through Failure. The Importance of Leadership and Open Communication.
Pedram Keyani Mar 11, 2014
Summly: An Award Winning Mobile App's Journey to the Cloud with Five-9s Availability on a Shoestring Budget
Eugene Ciurana Mar 11, 2014
Christophe Achouiantz Mar 11, 2014