Optimizing Performance in SuiteScript

Avoid loading a record if you don’t need to

Loading a record costs between 2 and 10 units of governance, and saving it costs between 4 and 20. Loading a record also loads metadata about the record, making the process take longer.

If you need to find values on a record, use a search. When creating or loading a search, minimize the columns to only those you need. Filter as much as you possibly can — it is faster to let the database fiddle with the data than for you to do so in your code (e.g., do not load an entire table and then go through the results yourself for a particular value — add a filter).

If you know the ID of the record you’re targeting, use search.lookupFields. It costs 1 unit of governance (compared to the 10 you would have to use to call getRange() or each() on a resultSet), and it’s faster.

If you need to change values on a record, use record.submitFields. It uses between 2 and 10 units of governance and is faster than loading and saving a record.

Set ignoreMandatoryFields to true

Tread with care here: ignoreMandatoryFields is an optional parameter of record.save() that is false by default. You can see a small performance increase by eliminating this data check when saving a record, although it should be used ONLY when the data coming in or out is completely controlled and validated for correctness or integrity by script.

Minimize the calls you make to the database

Grab as much of the data required as you can in the smallest number of queries. Use joins! When updating a record, track the values to be updated in code and do one save/submitFields call at the end of all your logic.

Another way to minimize disk calls is through consolidating scripts. It’s slower to access data in disk than it is to access data in memory, so the more you can get NetSuite to load into memory at once, the better.

Use Map-Reduce scripts

Map-Reduce scripts are insanely powerful — they handle parallel processing and governance management automatically and can be scheduled . Tasks that are a good fit for map-reduce are those that are logically “repetitive” — such as creating new records or updating values on a set of records. If you are thinking of using a Scheduled Script, think about if you can use a Map-Reduce script instead.

Utilize object mappings to minimize iteration

Say you have a list of Customers, and a list of invoices for those customers. A Customer can have more than one invoice, so how do you match them up? You can use a nested for-loop like so:

for(var i = 0; i < customer.length; i++) {
    for(var j = 0; j < invoice.length; j++) {
        if(invoice[j].customerId == customer[i].id) {
            // do something
        }
    }
}

But this iterates (i*j) times. If there are 100 customers and 500 invoices, that’s 50,000 iterations! Nested for-loops are necessary at times, and they work fine for finite datasets that won’t change significantly, such as a list of states. But for a potentially infinite datasets, such as a list of invoices, they can get unwieldy. Using an object map for this scenario could look like this:

var invoiceMap = {};
for(var i = 0; i < invoice.length; i++) {
    var customerId = invoice[i].customerId;
    if(!invoiceMap.hasOwnProperty(customerId)) {
        invoiceMap[customerId] = [];
    }
    invoiceMap[customerId].push(invoice[i]);
}
for(var j = 0; j < customer.length; j++) {
    var customerInvoices = invoiceMap[customer.id];
    // do something
}

Connect the two using the same value you were using in the comparison statement in the nested for-loops. You end up with the same information, but since they’re not nested, there are only (i+j) iterations. If there are 100 customers and 500 invoices, that’s 600 iterations compared to the 50,000 of the nested loop.

Resource: https://medium.com/@heavylion/optimizing-performance-in-suitescript-fe50d7cf1473