I've been working on some performance problems with SharePoint web parts.  We were able to narrow down the problem to a couple of things:

  • The web part traversed hierarchies of SPS Areas inefficiently.  The original code appeared to get the value of an Area's Areas property more than necessary:
    Dim objSubArea as Area 
    For intCounter as Integer = 0 To objArea.Areas.Count - 1 
     objSubArea = objArea.Areas(intCounter) 
     '''do some recursive processing 
    Next 

    Back in 2003 at a SharePoint developers conference in Redmond, the SP development team made it clear that SP collections should either be assigned to a variable before using them or enumerated using a for-each. They didn't say why, but after opening up the code in Reflector I can see why:

    public AreaCollection get_Areas()
    {
          aa.b().Demand();
          aa.a().Assert();
          return new AreaCollection(this.a.l());
    }
    

    With all of those security checks being performed and new AreaCollections being returned, the original code was likely resulting a in a lot of excess processing. Thus, we changed it to this:

    For Each objSubArea as Area in objArea.Areas
         
     '''do some recursive processing
     
    Next 

    In load-testing terms I don't know exactly how much this improves performance, but I compared the old and new web part code side by side using elapsed System.Environment.TickCounts and the new code appeared to take about 1/4 the time to load.

  • The web part had a feature that added document libraries and lists to the menu as menu items. The operations to find/load document libraries and lists are very costly:
    Area.Web.GetListsOfType(SPBaseType.DocumentLibrary)
    Area.Web.GetListsOfType(SPBaseType.GenericList)

    By “very costly“, I mean that the web part loaded much faster once we removed these calls altogether...

    What we actually found was that these calls were being made even when the feature wasn't even turned on . The calls were made ahead of time before the If...Then statement that checked whether the feature was turned on or off. It turns out that nobody1 was using this feature and management made the decision that it should be removed completely.

It turns out that the main performance problems could be resolved through improvement of the web part implementation rather than changing the design of the entire web part. At the beginning of all this I thought we would be working on the latter.

1 We used a tool that IWKid developed to browse all of the web parts in the entire site to see if they were using the IncludeAreaContent property/feature. We found none, and none of the business owners knew of anyone using the feature.