Question/Poll: Is it faster (better performance) to LOAD and run or to CREATE and run a search in code? What do you use and why?

I would think that running the search takes the majority of time, since that is an I/O operation. Possibly loading a search could take longer than a create since it uses I/O as well, but it is probably negligible compared to running the search.

So I'm trying to prove out which might be better to user and standardize with my team. I have my own reasons why I like to put the search directly in the code whenever possible. However, someone told me it's faster to run if the search is saved and loaded from the UI.

I have no performance metrics on the two, but I'm inclined to agree with @scottvonduhn for large result sets

Yes, most likely bigger differences will be seen between the N/search and N/query modules, than would be observed between a pre-existing vs. code-generated saved search. That is purely speculation. It's hard to do any solid benchmarks in a multi-tenant system to prove it, though.

In some very rudimentary browser console tests comparing an identical Query and Search, it took slightly longer to create the Query, but executing them was basically identical. A difference of a few dozen ms on average. But that was very rudimentary, simple setups. I'm working on a Query v Search article, and my recommendations will be coming down to feature sets, not performance/governance.

Given NetSuite's performance in general, I long ago stopped worrying about micro-optimizations in SuiteScript. It truly makes no significant difference when the overall system overhead will likely be the performance bottleneck, not my code. Best way to achieve good throughput is to by running fewer searches, using Map/Reduce scripts for concurrent processing, and caching values that will be retrieved multiple times. I also favor features over performance. The ability to join record types in a more flexible way will probably lead me to use the Query module more in the future, regardless of performance.

This ^ like a million times

OK. I'm with you guys on all this.

The only time I load a Saved Search is if it's something that needs to be modifiable by non-developers, or I often use them to drive Map/Reduce scripts and have the Saved Search be a Script Parameter.

I often like to load a saved search when the script consuming it may have changing needs or changing requirement in the future. A non-developer can simply adjust the search criteria (so long as they are careful not to remove any result columns), and can essentially change how a script behaves without coding.

Perfect. This is exactly what I do as well.

The best use case for creating a search in code is where the criteria or result columns are dynamic. In that case, I usually build the saved search in code using variables.

I have a situation where the scripts are running from a saved search in the UI but need specific columns. The user can change, and did, which cause a total rewrite of the code because they wanted to summarize some of the columns.

oy

exactly

For most of my saved search driven Map/Reduce scripts, I create two identical saved searches: one labeled "Script Use" and the other labeled "Report". People can modify the Report version and see how it affects the results without messing up the script. Then, if they want the changes made to the Script Use search, they have to submit a change request ticket, since those changes might break things.

I would adjust the setting of the saved search (under the audience tab) to make sure users cannot modify the search if it is being utilized for scripts.

That helps, but you can never prevent Admins from modifying a search though

Touche @erictgrubaugh. You would be operating under the assumption that Admins know better than to move columns around, haha. Big assumption, I know.

Yeah not always a safe one, sadly.

Haha. That's explicit. Hope it does the trick.

At that point, if they're still playing around willy-nilly, it's beyond my abilities to help them