Has anyone ever noticed any performance difference...
# suitescript
m
Has anyone ever noticed any performance differences between using a separate script for each customization or a single suitescript with everything or references other JS files as needed?
s
I don't have any hard numbers for you but in the case of UE scripts, it's better to have fewer scripts. I think this is mentioned explicitly in one of the NS guides (SAFE perhaps?)
this 1
e
^ This is my usual approach as well - one UE and/or Client script for everything that I own that routes to various supporting modules
👍 2
I also don't have numbers, but I do it strictly for organization and readability purposes
m
There was also a SuiteWorld presentation that talked about this and says that it improves performance, but as Shawn mentioned, few hard numbers.
👍 1
s
There is presumably a smallish perf gain by not firing up the outer script machinery multiple times, but a gain can be significantly high if multiple scripts would otherwise overlap with expensive operations. e.g. two scripts that need to execute an identical 8 second search would see big improvements through consolidation by only searching once. On the other hand there can also be architectural motivators to keep scripts separate or not, so it's a case-by-case basis for me.
e
I can confirm there is a performance difference as I ran tests for a previous employer of mine. They had ~5 UE scripts running on Sales Orders, all functionality was separated by script. We moved to 1 UE with multiple Modules and saw a pretty noticeable improvement. I no longer have the numbers, but it was signficant enough that we ended up consolidating our UE scripts across the board for many transaction types. I want to say it was 30-40% faster using a single UE script and calling functions from Modules.
👀 2
j
I went through an extensive effort with a previous employer to consolidate 20+ UEs against the Sales Order into as few as possible with the intent of improving performance. Got it down to 7. It helped drop a 35 seconds+ save time to about 25 seconds. But we discovered a bigger performance lift... we had around 10 different custom transaction forms for the Sales Order and hundreds of custom fields put in place for old integrations that were not being used. Inactivated all but 4 transaction forms and did the same for as many fields as possible. Doing that clean-up dropped saved time to 10-12 seconds consistently. Since that effort, any time I see excessive performance hits, I spend time looking at custom objects as much as I look at custom scripts.
👍 1
❤️ 1
e
It helped drop a 35 seconds+ save time to about 25 seconds. ‼️‼️‼️
Our users flipped tables when our Sales Order save time crept north of 10 seconds
j
Oh yeah, it was madness. The common practice was to open as many sales orders as possible each in their own browser tab. Work on the first one and save it, then move to the next and save and so on. The "game" was to see how many transactions could be worked before the first one finished saving. Imagine the impact of reducing save time from 35+seconds to 10. 10 is still long, but after 35 and with the measure of customizations they had that they wouldn't let go, they were ecstatic about 10 seconds.
💯 1
m
Thank you everyone. As the list of customization requests grow at my employer, looking to see if I need to start consolidating scripts or not.