Don't see much of performance improvement with SPFilterNode

May 28, 2012 at 11:10 PM

Hi Marc,

I'm using SPServices 0.7.1a and jQuery 1.7.2 for my customized SharePoint form and don't see much of performance improvement as described for the SPFilterNode function.

My form has 16 fields configured with rearrange (they are all radio buttons) and another 4 fields configured with auto-complete. It takes IE about 15 seconds to load the form and get it ready with the customizations.

I read Steve's blog post about javascript performance improvement trying to gain better understating of the find and filter functions, I then looked at the code in jquery.SPServices-0.7.1a.js for the rearrange function and found that in the GetList operation you don't use SPFilterNode. I'm assuming you might have a reason but either way I changed it to pilot test but without much success for the moment.

I'll be doing some more testing hoping to find some improvement in my form's performance.

Coordinator
May 28, 2012 at 11:37 PM

SPFilterNode isn't going to give you a performance improvement. As I point out in the docs, the point of it is to future proof us from changes the jQuery team may make around how we can select z:row or rs:data kinds of namespaces.

Given that you are calling SPArrangeChoices 16 times, there are 15 Web Services calls to GetList which are somewhat redundant. An enhancment that I can make (and will add to my list) is to cache the results of the Get:List call so that I only need to do it once per list per user page instance.

All of the calls to SPServices functions are simply going to take time. You're making a lot of calls. GetList doesn't need SPFilterNode because the namespace issue isn't in play. In fact, I believe that GetListItems is the only operation where it matters, but it's the most-used operation.

M.

Coordinator
May 28, 2012 at 11:40 PM

FYI - http://spservices.codeplex.com/workitem/10072

M.