Since the list of fields to add doesn't change (I assume) while the file is being used, you can just hard-code it into your code, instead of iterating over the entire file's (or page's) fields each time.
Alternatively, you can save all the fields' names into an array, and then split it by page number, on the doc-load event. That way you would only need to iterate over that array, instead of the actual fields, which is much faster.
Another option is to use the "dot" notation to group fields. Then use the "field.getArray()" function to get just the fields needed for the calculation.
Also, it's better to define the My calculation function at the document level so it's defined only once, when the document is opened.
Just doing this will help. Then you can use the same column summing function in every calculation. If you use the "dot" notation to group column fields, then the input parameter to this function would be the group name.
Calculations are always a performance issue because they are run every time any field on the form changes. The only way to deal with this is to minimize the number and size of the calculation scripts.
When creating a large PDF-form containing a few hundred fields and a lot of automatic calculated fields, huge performance issues occur. Navigating between fields using the tab key, will take multi seconds to process. My only guess is that any change to a field will trigger the re evaluation process of all fields and all calculated fields.
Eventually, we used a workaround to solve our PDF nightmare, using the feedback of Thom Parker and others.
app.calculate = false; this.calculate = false;
All scripts were saved on a document level. In the scripts, we looped over the required fields using the "dot" notation, limiting the ittiriation process significantly.
The best form designer from Adobe is the LiveCycle Designer, now called AEM, which makes no sense to me. Unfortunately, AFAIK, this tool does not create regular AcroForms. It's just for the big bucks enterprise crowd. It's always amazed me that they have this great platform for creating forms, but haven't made it available to the largest group of PDF forms in existence. It's like they want AcroForms to die.
InDesign is to too much of an expert tool to be used as a general form designer. If you're going have a good form designer, it has to be usable by the people who are creating the forms, not just design experts. Acrobat works on this level, so it is a good compromise, just not good enough.
There are 3rd party PDF form design products. I don't know anything about them, but I'd think that if someone was to create such a tool, the idea would be to make it better than the Acrobat "Prepare Form" tools.
You can actually create AcroForms from LiveCycle Designer... sort of. When you create a Static XFA form, a set of AcroForm fields also get created. If you have a COS editor, you can pop open the PDF, delete the XFA dictionaries and... poof!... you're left with a vanilla AcroForm.
At some point, I'll get around to posting a service that does this online.
Yeah, I invented this bit In fact, I created a plug-in years ago for making this conversion. It's pretty great, but its only a partial solution. For example, the field names are horrendous. And it only works for the layout portion. You still have to make all the appearance and scripting additions in Acrobat. Although several of these options could be handled through the plug-in.