Performance awareness is an essential skill of a NetSuite Developer, one that can draw a line between a good and bad script. Achieving a business requirement is only one part of the job but without proper performance consideration, it’s not enough. In this article, I compare two common approaches for finding the sublist line that contains a particular value.
As developers, we often need to find a sublist line with a specific value. There are two simple approaches frequently used to do this:
Record.findSublistLineWithValue native SuiteScript method or looping through all the sublist lines and comparing the values. While I was reviewing the code of other developers in the past, I noticed several times that they didn’t know about the existence of the
Record.findSublistLineWithValue method and used the other approach instead. So I was wondering, is the SuiteScript method just a fancy wrapper that does the same, or is there an actual performance difference, and if so, how large is it?
The first thing that would pop into our heads when we’re talking about performance in regards to NetSuite development is the SuiteScript Governance and limits. Luckily, none of these approaches consumes any usage units. So, I decided to conduct an experiment and I am pleased to share my findings with you.
The test record was a Sales Order (SO) with 500 item lines in a test drive (TSTDRV) account. Except for the testing script, there was no other custom script or workflow deployed on the SO record. The goal was to find one item line with a specific value, which was actually only present on the last, i.e., 500th line.
I conducted the experiment for client-side using a client script running the line search in the
pageInit entry point. It was executed in two Chrome incognito tabs with the SO with 500 lines open in edit mode and with no active Chrome extensions. The client script reloaded the page after it found the line, doing this 100 times for each tab.
I subsequently repeated the experiment using a scheduled script to see how the approaches perform server-side and to eliminate browser-specific effects. The script re-scheduled itself after each run.
The simple test script is shown below:
Several questions emerged during the experiment that led me to try a few variations of the code. Here is what I tried to get answers for:
- What is faster? Looping or
- Is there a speed difference between SuiteScript 2.0 and 2.1?
- Is the performance dependent on the field where I’m looking for the value? I tried to look in lineuniquekey, item, and quantity.
- Is there a speed difference between standard (deferred) and dynamic mode (only applicable for server-side in the experiment)?
Below are summarized results I got from 100 attempts for each variation (200 for client-side as I tested on 2 browser tabs). The table header says what field we searched for the value in, what kind of approach (‘loop’ or ‘find’), and variation (SuiteScript version and static/dynamic mode) was used. The reported execution times are in seconds. The best average result is highlighted in green color.
The answer to the first question, which approach is faster is pretty clear, it’s the SuiteScript
Record.findSublistLineWithValue method. What is faster, SuiteScript 2.0 or 2.1? It seems there is no real difference for looping approach but
findSublistLineWithValue performs better in SuiteScript 2.1 except for the lineuniquekey search where SuiteScript 2.0 marginally outperforms 2.1. Perhaps the takeaway here is to use SuiteScript 2.1 whenever possible as it gives better performance in general.
Is there a difference based on the field? Lineuniquekey seems to be slowest but the difference does not appear to be significant.On client-side, NetSuite's Record.findSublistLineWithValue could be up to 4.5 times faster than simply looping through all sublist lines in search of the target value. Click To Tweet
The client script did the searching on the actual record opened in the browser (
scriptContext.currentRecord). So, I also decided to try searching on loaded record (
record.load) instead, this time, only for lineuniquekey. The results were quite surprising. From the table below we can see that
findSublistLineWithValue performs significantly faster on loaded record!
S = record loaded in standard mode, D = record loaded in dynamic mode
|line unique key||loop|2.0|S||loop|2.0|D||loop|2.1|S||loop|2.1|D||find|2.0|S||find|2.0|D||find|2.1|S||find|2.1|D|
The winner is again without any doubts the findSublistLineWithValue method. SuiteScript 2.0 seems to be a bit faster for looping approach but also in this case we cannot answer the question unambiguously. Is there a difference between the fields – no, not really.On server-side, NetSuite's Record.findSublistLineWithValue also significantly outperforms the looping approach by more than 5 times in some cases. Click To Tweet
One extra question that I did not test in client side was whether there is any significant speed difference between standard and dynamic record mode. As can be seen from the above results, dynamic mode appears to be slightly slower in most of the cases, especially for looping approach. This is consistent with expectations as dynamic mode mimics the UI and thus, typically introduces some overhead.
One last quick test I did was to compare the performance of two approaches when searching for multiple values. The test was performed using SuiteScript 2.1 and record loaded in standard mode, searching for lineuniquekey present on 200th, 400th and 500th lines.
Based on the result of this experiment, I believe it is safe to state that
Record.findSublistLineWithValue is faster than looping and should be used if we need to find a unique (or the first instance of a) value in a sublist. SuiteScript version, record mode, and the actual field being searched for seem to be insignificant factors in determining the performance. There are other questions that one could further explore, for example:
- Do the results change when run using a sublist of a non-transaction record type e.g. a custom record sublist?
- Does it matter whether the field being searched for is a native field or a custom field?
The interested reader is invited to investigate further and share their findings.
NetSuite Insights is on a mission to raise the standards around NetSuite practices, one insight at a time. If that resonates with you, check out how you can become an author/collaborator here.
Also, subscribe to our no-nonsense email list to get these insights delivered to your inbox as soon as they’re published. Sometimes, ignorance is a choice. Choose wisely!