NewElementInHierarchy() - Adding New Elements, progressively takes longer when adding multiple siblings

Question

With my ESTK script, users select model numbers from a list and then the script inserts an element with a model number entered into an attribute, one element for each model selected.
When adding a large number of elements, each additional sibling element takes a little longer to add then the previous element. Adding 250 elements can take upwards of 3-1/2 minutes or more. While adding 20, 50, or 75 elements happens quickly, without any noticeable duration. It’s somewhere above 110 is where it starts to be noticeable.
I even used $.hiresTimer and wrote the value to the console for each time a model was added. Since the timer is reset back to zero (0) each time it's called, it was easier to notice that the amount it incremented from one element to the next got progressively larger.
Any thoughts as to why it’s taking so long or thoughts on what I could do to speed it up?
The structure looks like this:
<PartModels>
      <NoteText>Text</NoteText>
      <Model ModelNumber=”ABC01”/>
      <Model ModelNumber=”ABC02”/>
      <Model ModelNumber=”DEF03”/>
      <Model ModelNumber=”DEF04”/>
      <Model ModelNumber=”XYZ01-A”/>
      <Model ModelNumber=”XYZ*B”/>
      <Model ModelNumber=”XYZ500”/>
</PartModels>
The script is somewhat straight forward: cycle through an array of the model numbers selected, add a new element for each model number and set it's attribute value to the model number. This is the short version:
Function InsertModelElements (modelsToIns, insElemLoc, GVdoc) {
     var newEleId;
     var newElemLoc = insElemLoc;
     var elemDef = GVdoc.GetNamedElementDef(“Model”);
     for(var i = 0; i < modelsToIns.length; i++){ // modelsToIns is the array of models selected
          newEleId = elemDef.NewElementInHierarchy(newElemLoc); //ElementLoc based on NoteText first, last, or not present
          SetAttribute(newEleId, "ModelNumber", null, modelsToIns[i]); //more robust function to set attribute
          /*Which also works for setting attribute*/
          //var vattributes = newEleId.GetAttributes();
          //vattributes[0].values[0] = modelsToIns[i];
          //newEleId.Attributes = vattributes;
          /*At one point I tried using a new element location from the last inserted element, no change*/
          //var newElemRange = setElementSelection(GV_doc, EleId); //function that returns range
          //newElemLoc = newNewElemRange.end;
Any help is appreciated.
Sincerely,
Trent

Answer 1

Thanks Russ,
I seriously considered trying copy/paste and started to modify the code to do so. But I couldn't let it go, the answer had to be right there in front of me, just it's been too long since I've worked with this stuff, I'm not able to see it. Then it dawned on me what is happening.
In an earlier test, I placed a timer on each action that is looped through. For example, I start with an container element that has 200 children elements, each with a specific/unique model number attribute. All 200 existing elements are deleted and then replaced with 250 new elements with a different value for the model number attribute. The timer was placed after the Element.Delete() method and ElementDef.NewElementInHierarchy() method. What I noticed with the timer is that each element deleted was deleted faster than the previous element (so it progressively took less and less time to delete an element). And of course the opposite was noticed for inserting elements, each element inserted took longer than the previous element inserted.
These elements can be inserted in two areas of the structure, one of the areas has fewer format rules that impact the formatting and is actually a little quicker. This led me to the cause being the EDD format rules. The area that takes longer has quite a few extensive format rules that apply. Every time an element is inserted or deleted, FrameMaker runs through those rules to format the content of the elements. Since the rules apply to parent, first, last, next, previous, etc., FrameMaker has to apply format rules to all the elements in the structure that the rules apply to (which are extremely complex because of the various elements, attribute values, and combinations that can be inserted).
Removing or thinning down the FormatRules in the EDD, it does get quicker. But each of the FormatRules are needed. So using app.ApplyFormatRules = false; right before the elements are deleted and inserted works great. But the key is to set ApplyFormatRules back to true before deleting the last element to be deleted and before inserting the last element to be inserted, so it will cycle through all the format rules of the EDD for all the elements in the hierarchy those format rules apply to. Setting ApplyFormatRules to true and assigning the ElementDef to the last element also works [EleId.ElementDef = GV_doc.GetNamedElementDef(insElemType);], but only before any other functions are performed or different elements are added.
doc.Reformat() isn't going to reformat the content correctly after the fact because the element was created without the format rules, so it just reformats the content of the elements without the format rules.
The FDK version that was created 10 years ago had the same problem of running slow when a large number of elements were being inserted, but was still an improvement over having to manually insert each element and type in the attribute value, so it was lived with.
It's now working amazingly fast. I hope my explanation of what I think is happening, including the cause/solution, is understandable.
Sincerely,
Trent Schwartz