The following table shows the results of speed comparisons between different ways of implementing the same operations. It should be used as a guide when attempting to optimise IDL code. Results for scalar quantities are shown in YELLOW and results for array quantities are shown in RED. The number quoted in the third column is that which was used for the values of the scalar quantities or array elements in the test. Note that the tests were performed on a computer with 4 CPUs, which means that results may differ for other computers when IDL operations that employ the IDL thread pool are involved.

Further general optimisation hints are listed after the table.

The following general optimisation hints may also be useful:

• Needless to say, one should use array operations instead of "for" loops where possible, since IDL is optimised for such calculations.
• Avoid unnecessary variable type conversions by using variables of the same type where possible. This way IDL does not have to do the conversion itself.
• Ensure that operations on scalars are performed BEFORE the result is applied to an array, otherwise IDL will perform more array operations than is strictly necessary. For example:

  SLOWER (2000000 additions): a = fltarr(1000,1000) & b = 5.0 & c = 3.1 & x = (a + b) + c

  FASTER (1000001 additions): a = fltarr(1000,1000) & b = 5.0 & c = 3.1 & x = a + (b + c)

• If an array is being operated on and the result is overwriting the original array, then use the "temporary" function in the expression on the right-hand side, which avoids a copy of the original array being made before the operation is performed, resulting in a faster execution and less memory being used. Also use the "temporary" function on the right-hand side of an expression for a variable that will not be used again throughout the rest of the code, which again results in a faster execution and immediately frees up memory for the rest of the program. See the above table for some examples. Note that the "temporary" function should not be used on scalar quantities.
• When initialising an array with IDL functions like "intarr", "fltarr", etc., use the "/NOZERO" keyword if possible to leave the array elements undefined, otherwise the array will be initialised with all elements set to zero, which may be unnecessary. See the above table for an example.
• When inserting a sub-array into a larger array of the same dimensions, it is only necessary to specify the lowest subscript in each dimension for where the sub-array is to be inserted, rather than specifying the full subscript range in each dimension. This saves IDL from having to generate the subscripts for the relevant portion of the larger array before carrying out the insertion operation. For example:

  SLOWER: imdata[10:20,0:300] = imcutout

  FASTER: imdata[10,0] = imcutout

• When extracting a sub-array from a larger array, use the IDL "reform" function to give the sub-array the required dimensions. This avoids having to previously set up an array of the required dimensions to hold the sub-array, and then insert the sub-array into the new array. For example:

  SLOWER: vec = dblarr(n, /NOZERO) & vec[*] = arr[0,*]

  FASTER: vec = reform(arr[0,*], n)

• When comparing a scalar with an array (e.g. using the greater than comparison, etc.), one should be aware that if the scalar and array are of different number types, then IDL will convert the scalar and array to the more precise of the two number types. If it is the scalar that is of the more precise number type than the array, then the type conversion takes place on the array, which can introduce a large processing overhead. This processing overhead can be avoided by converting (or writing) the scalar to the number type of the array. For example:

  For an array "arr" of type BYTE and a scalar "val" of type INTEGER:

  SLOWER: subs = where(arr EQ val, nsubs)

  FASTER: subs = where(arr EQ byte(val), nsubs)

• Array concatenation such as:

  arr = [arr, extra]

  is very slow in IDL. It is faster to define an empty array of the correct size and insert the original array along with the new information. However, this is not always possible, especially if the size of the new information is not known in advance.
• The IDL "array_equal" function is a fast way to compare data for equality in situations where the index of the elements that differ are not of interest. This operation is much faster than using "total(a NE b)", because it stops the comparison as soon as the first inequality is found, an intermediate array is not created, and only one pass is made through the data. For best speed, ensure that the operands are of the same data type.