Skip to main content
dublove
Brainiac
June 19, 2025
Answered

What is the fastest way to reference an external function? Will it affect the speed?

  • June 19, 2025
  • 2 replies
  • 1049 views

I want to put some common functions in the same js for other scripts to call, is it necessary and will it affect the speed of the script?
What is the best way to reference external functions?
I see some people say //@include is better than #include is it?

Correct answer m1b

@dublove creating a "library" of functions is a great idea for your own scripts. It makes it much easier to maintain the functions—if you make an improvement to a function you just change it in that one library file, not every script that you ever put it into. However, if you make a change that breaks existing scripts, for example by changing input parameters or output values the scripts that include it will fail.

 

The *best* way to include a library of functions will depend on many factors, but I think in your case the best way is a simple

//@include 'path/to/script.js'

 

Note that #include 'path/to/script.js' is exactly the same as //@include—use whichever you like. If you use VSCode, then use //@include so it doesn't show a linting error.

 

The //@include 'path/to/script.js' line means that the entire code of script.js will be evaluated exactly as if it had been pasted in to your current script where that line is. This is the simplest way.

 

There are many other ways, and all solve specific problems, but all introduce issues too. I think keep it simple for now.

- Mark

 

P.S. just for interest, this is from a job I am working on now:

//@include '../Lib/IllustratorPackingAdapter.js'
//@include '../Lib/PackItems.js'
//@include '../Lib/TrentiumsPacker.js'
//@include '../Lib/Block.js'
//@include '../Lib/Bin.js'
//@include '../Lib/BinPacking.js'
//@include '../Lib/PackingAttempt.js'
//@include '../Lib/BinarySearchRange.js'

 Some of these "external" scripts are not very big, but I like to keep them separate. You can include as many as you need.

2 replies

rob day
Community Expert
June 19, 2025

Will it affect the speed?

 

Hi @dublove , If you are loading external libraries thinking it will improve a script’s performance, I don’t think that is the case. The advantage of libraries would be in building your own public methods and objects, but that is fairly advanced coding and you can certainly build complex, effective scripts without loading external code.

dublove
dubloveAuthor
Brainiac
June 19, 2025

Hi @rob day 

I'm sorry, maybe I didn't express myself clearly.
What I meant was: would using an external library be slower than calling it internally?
If I do have to use external libraries, which external call is better?

rob day
Community Expert
June 19, 2025

would using an external library be slower than calling it internally

 

There shouldn’t be any noticeable difference, but external libraries are going to be more challenging for a novice scripter. You should be able to load and evaluate a JSON file without calling an external library.

m1b
m1bCorrect answer
Community Expert
June 19, 2025

@dublove creating a "library" of functions is a great idea for your own scripts. It makes it much easier to maintain the functions—if you make an improvement to a function you just change it in that one library file, not every script that you ever put it into. However, if you make a change that breaks existing scripts, for example by changing input parameters or output values the scripts that include it will fail.

 

The *best* way to include a library of functions will depend on many factors, but I think in your case the best way is a simple

//@include 'path/to/script.js'

 

Note that #include 'path/to/script.js' is exactly the same as //@include—use whichever you like. If you use VSCode, then use //@include so it doesn't show a linting error.

 

The //@include 'path/to/script.js' line means that the entire code of script.js will be evaluated exactly as if it had been pasted in to your current script where that line is. This is the simplest way.

 

There are many other ways, and all solve specific problems, but all introduce issues too. I think keep it simple for now.

- Mark

 

P.S. just for interest, this is from a job I am working on now:

//@include '../Lib/IllustratorPackingAdapter.js'
//@include '../Lib/PackItems.js'
//@include '../Lib/TrentiumsPacker.js'
//@include '../Lib/Block.js'
//@include '../Lib/Bin.js'
//@include '../Lib/BinPacking.js'
//@include '../Lib/PackingAttempt.js'
//@include '../Lib/BinarySearchRange.js'

 Some of these "external" scripts are not very big, but I like to keep them separate. You can include as many as you need.

dublove
dubloveAuthor
Brainiac
June 19, 2025

Learned, thank you very much.
Mine is only 10 functions or less.
They are very small, so I wrote them all in one js to save time.
I also just learned about value conduction in functions, something I never understood before.

Not easy, another step forward.

m1b
Community Expert
June 19, 2025

Excellent! Every step forward is a win!

 

By the way, here is a good tutorial on Javascript ES3 which is almost identical to ExtendScript. It is in English, but I hope you can make sense of it.