Item12605: Performance issues with new Configure UI

Configure has some huge performance issues, especially on Chrome (and possibly other webkit browsers)

This task is to track performance issues with the new 1.2 configure UI. Two identified issues:

• All fields are auto-checked, not just fields with the FEEDBACK=AUTO option
  • This results in a large post when tabbing out of any modified field, or when clicking the "use default"/"use stored" selector
• The code that builds the post form uses an inordinate amount of CPU on Chrome - in the order of 10 seconds to build a post.

-- GeorgeClark - 17 Oct 2013

I think that the performance issue with chrome is fixed, but along the way it exposed another issue. The counter of "changed items" is managed on the server still, and is only updated by posting the whole config. There is no count of changed fields in javascript.

I think the solution here is to maintain an "estimate" of changed fields, in javascript, and update the button. It will be wrong if a field is changed more than once, but it at least will show activity, and clicking the button to show the changes posts the config and gets the correct value for changed fields.

-- GeorgeClark - 18 Oct 2013

Did some speed comparisons under chrome with regards to your fix by creating a form with 4000 input fields.

Method 1 - descend from a form searching for :input:

var start, end, len; 
start = new Date(); 
len = $j("form").find(":input").length; 
end = new Date(); 
console.log("len=",len,"diff=",end-start);

Method 2: descend from a form searching for input,  textarea, select, button:

var start, end, len; 
start = new Date(); 
len = $j("form").find("input, textarea, select, button").length; 
end = new Date(); 
console.log("len=",len,"diff=",end-start);

Method 3 - search for :input:

var start, end, len; 
start = new Date(); 
len = $j(":input").length; 
end = new Date(); 
console.log("len=",len,"diff=",end-start);

Method 4 - search for input, textarea, select, button:

var start, end, len; 
start = new Date(); 
len = $j("input, textarea, select, button").length; 
end = new Date(); 
console.log("len=",len,"diff=",end-start);

Method	Chrome	Firefox
1	2000-3300	31
2	10	7
3	10	9
4	3	3

Numbers are milliseconds. Tested using jquery 1.8.3, 1.10.1 and 2.0.2. The performance breakdown for $("form :input") is consistent on chrome for all jquery versions.

-- MichaelDaum - 18 Oct 2013

With regards of configure not being able what changed ... doesn't that sound pretty lame? As far as I see it alread does add a class foswikiValueChanged to an input element with changes. So counting them is next to trivial using $(".foswikiValueChanged").length. What am I missing?

However, it doesn't remember what the original value was the user changed it to and thus doesn't remove the foswikiValueChanged class in case the user reverted the change.

Another strangeness is that when I close the browser tab with configure and reopen the url again, then configure still remembers the changes that I did before. Is this a feature?

-- MichaelDaum - 18 Oct 2013

Configure now uses a "Shopping Cart" concept, you can leave your configuration and come back later without needing to save it.

The tracking of changes is still done using the "old configure" model. When you post the form it returns a div containing the pending change information. The redesign of configure still has a way to go:

• Post individual changed elements instead of the entire form
• Generate the list of pending changes locally instead of on the server

For now as a "quick fix" we could change configure to go back to posting the entire form on each change. Or maybe update the button text with a generic "changes pending" when local changes have not been sent to the server.

Or go "all out" and continue the redesign toward a fully restful implementation.

If the performance problem is fixed, we should probably close this one, and open a task to track additional issues. I don't like the "mega tasks" that cover a wide variety of issues.

-- GeorgeClark - 18 Oct 2013

There are still performance issues, but they cannot be resolved without a huge amount of work. For now, we are going to have to live with it.

Downgrading to "Normal". See also Item12605 which describes a sub-problem.

-- CrawfordCurrie - 25 Apr 2014

Changing this to no action - This is all regarding the first 1.2 configure rewrite. Crawfords rewrite has made all this moot.

-- GeorgeClark - 02 Dec 2014

Commenting is disabled while not logged in