Performance Considerations With the PeopleEditor Control

I was recently working on a Black Ninja Software project for a client of ours where performance became an issues for one of the custom application pages we had developed. I plan to write up a more detailed report on how I managed to cut the load times of this particular page in half using the ANTS Profiler, but for now I wanted to highlight a piece of the puzzle that I discovered today.

I won’t cover how to load values into a PeopleEditor control from within a SharePoint list, you can view that in more detail here.

Take a look at the example below:

1
2
3
SPFieldUserValue user = new SPFieldUserValue(web, Convert.ToString(listItem["Employee]));
 
peEmployee.CommaSeparatedAccounts = user.LookupValue;

If we have an SPFieldUserValue object, calling upon the LookupValue property will return the Name of that user. This is not to be confused with the LoginName property. Assigning that to the CommaSeparatedAccounts property may do the trick and will load that user account into the control but not without a performance hit.

A better approach would be:

1
2
3
SPFieldUserValue user = new SPFieldUserValue(web, Convert.ToString(listItem["Employee"]));
 
peEmployee.CommaSeparatedAccounts = user.User.LoginName;

The difference is minor. Instead of using the LookupValue property, we leverage the SPUser object and call upon the LoginName property. In all of my testing, I noticed an improvement in speed when using the LoginName property.

Depending on your environment, the output from either of those properties will differ and that’s the heart of the performance issues. In my environment, LoginName and Name outputted the following:

Name – “Joe User”
LoginName – “domainjuser”

Having the domain specified seems to speed this whole process up. I would be interested to hear from anyone else who’s encountered anything similar.

, ,

No comments yet.

Leave a Reply