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.

Poor performance for large form with lots of empty fields

  1. I've just done some troubleshooting work for a client who has a very large form (over 200 fields). It uses conditional logic to hide most fields and only reveal them upon certain input selections.

    When most of the fields are filled, the form processes to completion without problem in under 60 seconds (their script timeout). However, when most of the fields are empty, the form processing blows out to about 200 seconds (tested on my dev box, 3.6GHz 64-bit multicore with 16GB RAM). I've had to up their script timeout to 300 seconds to ensure they get their form submissions.

    What seems to be happening is that fields with values go through GFCommon::replace_variables() once, but fields with no values go through that loop four times. Thus, the more empty fields a form has, the worse its performance.

    Time for some rocket surgery! (e.g. check for empty before iterating over GFCommon::replace_variables() four time?)

    cheers,
    Ross

    Posted 7 years ago on Wednesday December 12, 2012 | Permalink
  2. Can you please export this form and email it to me at chris@rocketgenius.com ? I will bring this to the attention of the development team.

    Posted 7 years ago on Thursday December 13, 2012 | Permalink
  3. Thanks for all the details and the troubleshooting. We will be looking at this and see what we can do to improve performance in that area.

    Posted 7 years ago on Thursday December 13, 2012 | Permalink
  4. Thanks guys, the form is on the way.

    cheers,
    Ross

    Posted 7 years ago on Thursday December 13, 2012 | Permalink
  5. We have your form. This may not be something we can address right away but it has been added to the list.

    Posted 7 years ago on Friday December 14, 2012 | Permalink

This topic has been resolved and has been closed to new replies.