Alot depends on how complex the layout on which the script was performed AND how complex the table is.
Good rule of thumb is to run data manipulation scripts as perform script on server when possible because server generally runs faster than client.
Controls on the layout and calcs/lookups on the table = impact to performance.
Run long scripts from "thin layouts" that is layouts with minimal controls.
Also freeze window at the top of a script may speed things up.
Yeah, it takes longer because you are adding at least an extra 14,000 commands.
If you just use:
Replace Field Contents [ PackagedItem::Vendor_ID ; if ( IsEmpty(PackagedItem::Vendor_ID) ; "the vendor ID" ; PackagedItem::Vendor_ID ) ]
Then you can do ALL of that in one script step, taking much less time.
Essentially, right now, you are doing:
7,699 go to record script steps
7,700 "if" script steps
x number of "set field" script steps
If you index the Vendor_ID field, and change it to the single script step instead of a loop, then it should be much faster.
You can make it even faster (seconds really) by using Perform Script on Server if the file is hosted in 13+ as well.
2 of 2 people found this helpful
If you are using a hosted file and not using perform script on server, then it also is probably slowing down from "progressive loading syndrome". A phenomenon for large looping actions where the loop gets progressively slower as it executes since it has to follow the data flow order of:
-Request record from server
-Transfer record to client
-update record on client
-request commit action to server
-return result of commit to client
-return updated record to client
-repeat ad nauseum.
1 of 1 people found this helpful
One last note, related data will always slow down actions as well due to the above. Say for example you are referencing the Vendor_ID from another Vendors table to pull into PackagedItem, Not only is it pulled the PackagedItem record, but also the related Vendor record as well.
Other things that can slow down these kinds of actions are unstored calculation fields, summary fields (EG if you have a summary field on the layout you are using, it may update the summary before moving on in the loop). Those things in either the main or related table can cause loop actions to slow.
Thank you for the info, it make sense. I changed the script and re-ran it.
Yikes! 4 seconds!
Learned a big lesson today, thank you.