PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

More on performance of large forms with empty fields

  1. Further to my post Poor performance for large form with lots of empty fields, 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.

    On my dev box, the original form was taking about 200s to process with 120 empty fields, some used in calculations.

    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.

    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. :)

    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.

    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).

    cheers,
    Ross

    Posted 7 years ago on Saturday January 12, 2013 | Permalink
  2. 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.

    Posted 7 years ago on Saturday January 12, 2013 | Permalink
  3. 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.

    Posted 7 years ago on Saturday January 12, 2013 | Permalink
  4. G'day Chris, thanks for the update.

    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:

    1. sum of #students
    2. sum of #class trainers
    3. sum of #additional trainers
    4. (sum of #students) + (sum of #class trainers) + (sum of #additional trainers)
    5. ((sum of #students) + (sum of #class trainers) + (sum of #additional trainers)) * 100
    6. ((sum of #students) + (sum of #class trainers) + (sum of #additional trainers)) * 50

    By removing redundant calculations, I was able to drop the processing time from 200s to 36s.

    1. sum of #students
    2. sum of #class trainers
    3. sum of #additional trainers
    4. (1) + (2) + (3)
    5. (4) * 100
    6. (5) / 50

    I wish I'd noticed that before! I just hope the client is still happy with the new compound fields :)

    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!

    cheers,
    Ross

    Posted 7 years ago on Monday January 14, 2013 | Permalink
  5. 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.

    Posted 7 years ago on Monday January 14, 2013 | Permalink