4 minute read
I got a question today via Twitter and my blog that I thought I’d share:
Further to Twitter message, I need to lookup values in a large list (thousands of items). Now, list performance and architecture issues aside, my intention is to use some JQuery enabled textbox which makes web service calls to suggest matching results as the user types. That’s not complex and I’m quite happy doing that. As with every time I use JQuery, I always think "should I really be solving this problem this way?". Making multiple web service calls as a user types (even with a delay) still seems wrong. I’m just not sure there’s another way to resolve the problem. What do you think?
As you know, Eric Shupps and I traded thoughts (along with a large number of other people) on this a while back:
- Putting the Brakes on SharePoint with JQuery
- Putting the Brakes on SharePoint with jQuery – Or Not
- Putting the Brakes on SharePoint with jQuery – Or Not (Some More)
- Follow-Up on JQuery and SharePoint Performance
I think that Eric and I reached the point where we realized that we were basically both saying that jQuery doesn’t kill performance: people kill performance.
There are good ways and bad ways to come at the problem. Let me break down my thoughts…
First of all, "large lists" are, to a large degree, SharePoint myths. The real performance hit comes when you attempt to work with or display all of the items. As with any development, no matter the platform, the language, or the requirements, you have to be smart about it.
Secondly, it’s all about the use cases. A relatively slow page which is used a few times a day is a very different situation than a slow home page. You always have to consider who will be doing what, how often, why, etc.
Thirdly, when you use client-side code, you’re asking the client machine to do at least some of the work for you. It’s very important to know what your client machine profiles are likely to be. If it’s a corporate environment, you already know the machine profiles. (Right? You’ve done an inventory and you’re keeping it up to date so that you know what you can and cannot do?) If it’s an Internet site, then do you want to support Opera 5.0 as fully as IE8? Do you want to be able to assume that client machines have more than 1Gb of RAM or can support Flash or Silverlight? etc.
Lastly, from all of my experience using jQuery with the SharePoint Web Services, I’ve found them to be extremely efficient. Basically, if you are doing something that you would expect to be non-performant through the UI, you can expect to see similar non-performant behavior with the Web Services, though it seems to me in many cases that the Web Services can actually be more efficient. If you think about it, this makes sense. You’re working at a lower level than full page refreshes, which requires much more work on the server’s part.
So, I’m not trying to dodge the questions; I just wanted to give a little of my perspective going into the specific answers.
"Should I really be solving this problem this way?"
Assuming that it will meet the requirements, I say "absolutely". If this approach is going to give your users a good experience, then do it. There are several things you can to to mitigate potential issues.
Probably the biggest mitigation would be to cache the GetListItems results. If you can assume (note that I’m being careful about my assumptions; I know no more that what is in the questions above) that the "large list" is unlikely to change in a material way while the user is working with this piece of functionality, then making a single Web Service call and caching the results for the life of the page (or some decent time period) will keep the Web Service calls to a minimum.
Waiting for the user to type a certain number of characters before starting to do the Web Service calls can also help. Going out and grabbing all of the items which have a value that starts with "T" may not even really be helpful, where "Thr" might be. If you look at my $().SPServices.SPDisplayRelatedInfo, I allow you to set the number of characters for just this reason.
Oh yeah, that reminds me: also consider using my jQuery Library for SharePoint Web Services. ;+)