This project has moved and is read-only. For the latest updates, please go here.

Performance Limits for SPCascadeDropdowns

Sep 10, 2013 at 3:05 PM
Hey there,

I'm using SPCascadeDropdowns to create Cascaded dropdowns between two columns. The parent column has about 10 items, but the child column has 1400. This results in the edit/new item form taking about 80secs to load as the SPCascadeDropdowns methods are called on the dropdowns.

Common sense tells me that having a massive dropdown like that is the obvious culprit for such poor performance. I searched for any documentation that indicated recommended limits to the size of dropdowns but couldn't find anything.

Are there recommendations to dropdown size? Any way around this performance hit?

Sep 10, 2013 at 3:28 PM
I don't have any real limits on the function. There are a lot of variables, including farm horsepower, that can have an impact.

Given that you have 10 parents, logic tells me that on average you'd be retrieving 140 items per change on the parent. That's not really a concern. 80 seconds makes no sense to me at all, so there must be something else going on.

Take a look at the traffic in Fiddler or Firebug. It may give you a clue as to what's happening.

Sep 10, 2013 at 3:32 PM
Hey Marc,

Thanks for the response. The number of items per change can vary, some parents only have 8 childs, others have a few hundred.

But your idea to use Firebug is a good one, I'll see what it throws up.

Sep 10, 2013 at 3:47 PM
Hopefully it doesn't "throw up" anything too horrible. ;+)

One other question: what versions of SPServices and jQuery are you using?

Sep 11, 2013 at 8:50 AM
I'm using the following versions:

I used IE8's profiler to look at the timings (it's the only browser available to me) and the main culprits appear to be GipRefreshGroupCore and GipSplit. These are functions within GroupedItemPicker, a SharePoint JS library. These two functions account for 75-80% of the load time.
Sep 11, 2013 at 9:07 AM
Sorry, should add that the parent column is a dropdown but the child column uses a grouped item picker. Perhaps this isn't the intended target for SPCascadeDropdowns as it is only intended for dropdown to dropdown?
Sep 11, 2013 at 3:29 PM

The "Gip" functions all service the multi-select "dropdown", and that is absolutely supported in SPCascadeDropdowns. The way this all works is that the form loads as it normally does, and then the script takes over to filter the data that's already there. In order for things to work properly on submit, I use the existing functions that drive the GIP because they manipulate a bunch of JavaScript variables under the covers that are needed for the submit to work.

You're using the latest version of SPServices, which is as efficient as I've been able to make things. I'm not saying that it's perfect, but in every version I manage to get some performance improvement. It may be that with your mix of content, the inefficiencies are showing more than for others.

The other thing to consider here is that this all runs on the client side. For that reason, you need to understand the machine parameters and understand that a slow machine will really matter.

Sep 11, 2013 at 3:46 PM
Thanks Marc,

I have a feeling the performance is more to do with our content and client and server machine performance than your code. I think the business requirement we have probably doesn't fit to the capability of SP.
Sep 11, 2013 at 3:48 PM
Nothing you've described so far is something you shouldn't be doing in SharePoint.

Sep 12, 2013 at 8:25 AM
Ah, but I haven't shared the complete story! ;)
Sep 12, 2013 at 1:14 PM
The real story is always longer. ;+)