19 Feb

SharePoint: Performance Problem with LookupField Control

The Microsoft.SharePoint.WebControls.LookupField control is used as the default control when editing a lookup field value. When the list that is referenced by the lookup field contains hundreds or thousands of items – it takes this control a while to gather all items that will be displayed – slowing down the page performance when requesting the edit page of your list item.
Following illustration shows a standard list and how you would start editing an item:
Select an Item to be edited

Select an Item to be edited

The upcoming standard Edit Form will use a LookupField control to display the current lookup value and the possible values taken from the referenced table.

Standard Edit Form using Lookup Field Control to display all referenced items

Standard Edit Form using Lookup Field Control to display all referenced items

Performance problem of LookupField control

It makes sense that the page rendering takes longer the more items there are in the referenced list. I was however surprised to find the page performance to be very slow when pressing the OK button on the edit page after you have made changes to your edited list item. I thought that this should be a rather quick operating – doing a simple update and then returning to my SharePoint list.

It turned out that submitting my changes took as long as requesting the edit form page. Looking insight into whats going on revealed the reason for that. It seems that the LookupField control also retrievs all items in case of a Page Postback – which happens when clicking the OK button. This might be intentional due to input value validation but it definitely slows down your page performance. The following PurePath shows what happens at the Page Postback:

On a page postback - the LookupField control spends 6 seconds in CreateChildControls where it queries the values to display

On a page postback - the LookupField control spends 7 seconds in CreateChildControls where it queries the values to display

In my example above I had 1000 items in the referenced list – causing a page rendering and postback time of almost 10 seconds where 7 seconds where spent by the LookupField control.

Conclusion

I am not sure if this behavior is intentional. In any case you may want to think about using an alternativ control in case your lookup list contains a large number of items.

Comments
5 comments yet
  1. [...] SharePoint: Performance Problem with LookupField Control [...]

  2. I ran into this problem. The solution for that was to create an AJAX based Custom Field Control that filtered the list in the first place. Who would like to see a 1000 list items in a LookUp field?

  3. Thanks for that comment – good workaround

    I am sure Microsoft is also going to address the problem so that the control doesnt refetch all data upon the PostBack of the page

    Cheers

  4. Elvira @ 2011-09-20 13:00

    I believe there are lot of problems that contribute to performance bottlenecks in SharePoint however it is a very useful extremely popular product that improves effectiveness of organizations through content management and enterprise search, shared business processes, and information-sharing across boundaries for better business insight.

    The SharePoint performance problems occur primarily due to the following reasons:

    - BLOBs overwhelm SQL Server
    - Too many database trips for lists

    You can dramatically improve SharePoint performance if you use a few of intelligent techniques which are:

    - Externalize Documents (BLOBs)
    - Cache Lists and BLOBs

    StorageEdge provides precisely such a blob caching facility. It offers a unique combination of externalization and BLOB caching for effective blob management and access from a single interface. It makes use of NCache® technology to let you cache frequently used BLOBs in a distributed fashion with high availability, complete replication and failover. A distributed cache can give your SharePoint infrastructure a significant scalability boost because it keeps things distributed across multiple servers and still giving one logical view. But the cache actually lives on multiple servers and that’s what allows the cache to really scale.

  5. Good information about performance engineering thanks for providing this interesting post.Thanks for your posting its good information and its use full to the peoples.

Add your comment now

*