Rendering slow when having lots of custom fields and rules

[Jan Beilicke]

The plugin works like a charm in general. Unfortunately, the rendering of a ticket takes about 10s in Chrome 16 (and even more in FF) when having about 45 custom fields that should be hidden or displayed depending on components and ticket types.

According to some quick tests, the performance issue might be caused by several nested $.each() in dynfields.html​, one time in the function apply_rules() and in the jQuery(document).ready() part.

Do you see any chance that this part might be refactored to improve the performance?

[Jan Beilicke]

I've investigated the issue further:

• Replaced jQuery.each() with native JavaScript for-loops: No performance gain.
• Set some console.time() measuring points: It turned out that moving each field in the DOM triggered in layout.js​ causes the slow-down.

[Rob Guttman]

jbeilicke, really appreciate you investigating performance issues here. I admit I have not concerned myself with performance oprimizations as I haven't personally seen problems - but then I have a lot less fields than you do it seems.

Let me know what you find in your profiling and I'll be happy to attempt fixes accordingly.

[Onur Baykal]

Sorry to rise this ticket from the dead. I have the same issue. I have a trac 1.0.8 installed on a ubuntu machine with DynamicFields 1.2.6 installed (compiled from latest revisions 0.11 folder). I have more than 100 custom fields with 30 ticket types. Each field has its own rule. Even loading the new ticket page takes about 30 seconds on a modern machine. And when a user selects a different type of ticket, it takes close to 20 seconds to reload. I assume automatic ticket preview feature also effects this but I mainly think there are some inefficiencies in the js code. Disabling Rules doesn't seem to speed up the page loading. I'd be happy to provide more detail to solve this problem.

Also we used to have a 1.0.1 installed on a mac with DynamicFields 1.2.1 installed. Somehow the plugin works faster with that configuration (same field & ticket types). I'm suspecting the underlying DOM operations for this problem since on 1.2.1, fields disappear after the rendering of the page.

[Ryan J Ollos]

You might want to try installing from the trunk​. The 0.11​ branch is unlikely to be maintained going forward.

[Onur Baykal]

Just compiled from trunk and installed. The problem still exists.

[Ryan J Ollos]

I'm not sure that I'll have time to take a look at this. However, attaching your [ticket-custom] section would greatly help in reproducing the issue. It sounds like the section is large, so please attach it as a file rather than pasting in a comment.

The output of trac-admin $env ticket_type list would also be useful. You can just paste that as a comment.

[Onur Baykal]

I've attached the [ticket-custom] field. Also here are the ticket types:

Sorun               
Test                
EGGIM               
MeetingAI           
UcusTalimati        
YDI                 
UcusAI              
UretimITF           
ACGIM               
InfEGG              
CodeIssue           
LeasonsLearned      
IntegrationIssue    
ToolIssue           
TestIssue           
IsTakibi            
Gereksinim          
YGT                 
Task                
TestTalimati        
AYESAS_FIX          
AYESAS_PLAN         
ComponentDescription
CAWS                
KarayelUcusAI       
Açıklama            
SahaTalep           
SesliUyari          
Release   

[Ryan J Ollos]

In 14895:

2.2.0dev: Trivial optimizations and code style changes suggested by linter. Refs #9606.

[Onur Baykal]

Your latest commit somewhat improved rendering times but still locks the browser.

[Ryan J Ollos]

In 14896:

2.2.0dev: Move functions inside document ready handler. Refs #9606.

No performance change is expected.

[Ryan J Ollos]

In 14897:

2.2.0dev: Minor selector optimizations. Refs #9606.

[Ryan J Ollos]

Looks like 90% of the time is being spent in order_fields​. I'll try to look into improving that, but it will be at least a few days before I have time.

[Ryan J Ollos]

In 14898:

2.2.0dev: Minor selector optimization. Refs #9606.

[Ryan J Ollos]

In 14905:

2.2.0dev: Fix errors in [14896].

The functions get_selector, apply_rules and setup_triggers needs to be global scope.

Refs #9606.

[Ryan J Ollos]

In 14906:

2.2.0dev: Use jQuery is to compare element type.

Refs #9606.

[anonymous]

Hi @rjollos. I am using this plugin too and we have a serious issue same as @theaob. Rendering is too slow when having lots of custom fields and rules and I can't open 3 tabs at the same time in my Trac.

Are you still trying to improve the plugin's performance? I am really sorry to wake up this old thread. Good work.

[Ryan J Ollos]

I haven't had time to work on the plugin much lately because I'm working on Trac, and my JavaScript knowledge is also fairly limited. I recall doing some profiling and finding where time was being spent, but didn't see a way to fix it.

I'd gladly test a patch from anyone that wishes to contribute.

[anonymous]

Thanks.
Can you give us some specific target to look on? So we can try to figure out what is causing this problem.

[anonymous]

Replying to anonymous:

Thanks.
Can you give us some specific target to look on? So we can try to figure out what is causing this problem.

OR Is there any alternative plugin etc. that we can count on?

[anonymous]

Hi all;

Same problem. Can any one fix this order_fields script? We need the plugin desperately but having it also makes you wait desperately to have the page loaded.

[Jun Omae]

I tried to optimize DOM operations: t9606-optimize-dom-operations.diff​.

Timing of apply_rules reduces from 2500ms to 850ms with 100 custom fields.

[Ryan J Ollos]

Thank you for the patch. I'll test the changes.

[Ryan J Ollos]

This issue was discussed on the ​MailingList in ​gdiscussion:trac-users:Mau5CQ0fGvY.

[Ryan J Ollos]

The optimization in comment:25 patch are:

• Add local variable to avoid repeatedly referencing objects, such as window or this
• Use some pure JavaScript methods rather than jQuery (e.g. getElementById)
• Use strict operators (e.g. === rather than ==)
• Save field name in data-dynfields-name attribute (for faster retrieval?)
• Refine/minimize-repeated selectors
• Get attribute from JavaScript object rather than from jQuery object using jQuery method

[Ryan J Ollos]

Rebased patch.

[Ryan J Ollos]

In 17521:

TracDynamicFields 2.3.0dev: Optimize code

Patch by Jun Omae.

Refs #9606

[Ryan J Ollos]

Replying to Ryan J Ollos:

Looks like 90% of the time is being spent in order_fields​. I'll try to look into improving that, but it will be at least a few days before I have time.

It appears that Layout.update (which calls Layout.order_fields) is being called repeatedly. It looks to me like the layout should be updated just once, after applying all the rules. As a further optimization, we could have the rules set a flag that determines if the layout needs to be updated, in order to avoid unnecessary updates.

I tried the following patch, which makes the update very fast, but the layout is not applied correctly. Some fields incorrectly end up with their own row. I will continue to investigate whether this is a valid approach. Jun, do you think this approach should work?

dynfields/htdocs/dynfields.js

@@ -36 +36 @@
         spec.rule.complete(input, spec);
       });
     });
+
+    // update layout (see layout.js)
+    inputs_layout.update();
+    header_layout.update();
+
   };
 
   window.setup_triggers = function () {

dynfields/htdocs/layout.js

@@ -22 +22 @@
     return element !== null && element.tagName.toLowerCase() === 'textarea';
   };
 
-  // Update the field layout given a spec
-  this.update = function (spec) {
+  // Update the field layout
+  this.update = function () {
     var this_ = this;
     var name = this.name;
 

dynfields/htdocs/rules.js

@@ -222 +222 @@
 hiderule.complete = function (input, spec) {
   jQuery('#properties .dynfields-hide, #ticket .properties .dynfields-hide').hide();
 
-  // update layout (see layout.js)
-  inputs_layout.update(spec);
-  header_layout.update(spec);
-
   // add link to show hidden fields (that are enabled to be shown)
   if (spec.link_to_show.toLowerCase() == 'true') {
     if (jQuery('#dynfields-show-link').length == 0) {

[Ryan J Ollos]

In 17522:

TracDynamicFields 2.3.0dev: Fix fields not hidden in header during preview

Patch by Jun Omae.

Refs #12575, #9606.

[Ryan J Ollos]

Replying to Ryan J Ollos:

I tried the following patch, which makes the update very fast, but the layout is not applied correctly. Some fields incorrectly end up with their own row. I will continue to investigate whether this is a valid approach. Jun, do you think this approach should work?

The patch seems to work correctly after r17522.

[Ryan J Ollos]

In 17523:

TracDynamicFields 2.3.0dev: Update the layout once after rules applied

Refs #9606.