https://legacy.forums.gravityhelp.com/topic/more-on-performance-of-large-forms-with-empty-fields Gravity Support Forums Topic: More on performance of large forms with empty fields en-US Sat, 04 Apr 2026 18:08:28 +0000 http://bbpress.org/?v=1.0.1 q https://legacy.forums.gravityhelp.com/search.php https://legacy.forums.gravityhelp.com/topic/more-on-performance-of-large-forms-with-empty-fields#post-121549 Mon, 14 Jan 2013 10:13:36 +0000 Chris Hajer 121549@https://legacy.forums.gravityhelp.com/ <p>I'll send them a link to this topic again in case they did not get the update. Sounds like you're making good progress. Thanks for letting us know. </p> https://legacy.forums.gravityhelp.com/topic/more-on-performance-of-large-forms-with-empty-fields#post-121147 Sun, 13 Jan 2013 22:42:22 +0000 webaware 121147@https://legacy.forums.gravityhelp.com/ <p>G'day Chris, thanks for the update.</p> <p>On a hunch, I took another look at the original form, and discovered that they had built it with redundant calculations, summing things three times:</p> <ol> <li>sum of #students </li> <li>sum of #class trainers </li> <li>sum of #additional trainers </li> <li>(sum of #students) + (sum of #class trainers) + (sum of #additional trainers) </li> <li>((sum of #students) + (sum of #class trainers) + (sum of #additional trainers)) * 100 </li> <li>((sum of #students) + (sum of #class trainers) + (sum of #additional trainers)) * 50 </li> </ol> <p>By removing redundant calculations, I was able to drop the processing time from 200s to 36s. </p> <ol> <li>sum of #students </li> <li>sum of #class trainers </li> <li>sum of #additional trainers </li> <li>(1) + (2) + (3) </li> <li>(4) * 100 </li> <li>(5) / 50 </li> </ol> <p>I wish I'd noticed that before! I just hope the client is still happy with the new compound fields :)</p> <p>I still would like to see Gravity Forms improve performance though, as 36s is still pretty horrible, but please let the developers know that things are not as dire as they seemed!</p> <p>cheers,<br /> Ross </p> https://legacy.forums.gravityhelp.com/topic/more-on-performance-of-large-forms-with-empty-fields#post-119940 Sat, 12 Jan 2013 02:03:36 +0000 Chris Hajer 119940@https://legacy.forums.gravityhelp.com/ <p>I heard back from the development team. They're aware of the issue and know there is room for improvement. Some changes will be added to our next release and fine-tuned after that. Thanks once again for all your hard work investigating this. </p> https://legacy.forums.gravityhelp.com/topic/more-on-performance-of-large-forms-with-empty-fields#post-119915 Sat, 12 Jan 2013 01:06:04 +0000 Chris Hajer 119915@https://legacy.forums.gravityhelp.com/ <p>The developers asked me for your original form a couple days ago, so I know they are looking at this. I will send them your additional information. Thanks for taking the time to write it up. </p> https://legacy.forums.gravityhelp.com/topic/more-on-performance-of-large-forms-with-empty-fields#post-119902 Sat, 12 Jan 2013 00:46:42 +0000 webaware 119902@https://legacy.forums.gravityhelp.com/ <p>Further to my post <a href="http://www.gravityhelp.com/forums/topic/poor-performance-for-large-form-with-lots-of-empty-fields" rel="nofollow">Poor performance for large form with lots of empty fields</a>, I've just about wrapped up a custom plugin that replaces a bunch of fields on this form with some compound fields, thus reducing both the number of empty fields seen by Gravity Forms and the number of fields used in calculations. Doing this has had a dramatic effect on processing time.</p> <p>On my dev box, the original form was taking about 200s to process with 120 empty fields, some used in calculations.</p> <p>Reducing the number of empty fields by replacing 150 fields (up to 120 empty) with 20 compound fields (up to 16 empty) reduced the processing time from 200s to 75s.</p> <p>Rewriting the calculations for this form so that they used server-side calculated totals on gform_pre_render (which was required for the new compound fields -- how many laptops are there in a classroom field?) enabled the calculations to become very simple, just (students + class participants + additional participants), i.e. adding together 3 elements instead of 30. This reduced processing time to 3s. Three seconds. :)</p> <p>One of the biggest parts to this is, in my opinion, that GFCommon::get_submitted_fields() is called many times during the course of GFCommon::replace_variables(), and each call requires an iteration over the form's fields triggering any filter hooks applicable along the way. I'm not sure what you can do about that, but it certainly seems to be where a lot of processing time goes.</p> <p>Let me know if you need any further information about this from me. I've already sent their original form, so you will have seen what they were doing (and in particular, the calculations involved for the fields on the final page).</p> <p>cheers,<br /> Ross </p>