Syntax Speed Tips for LP8.5

Tips for choosing the syntax that will execute the fastest.

Incrementing

$x += 1

is faster than

$x = $x + 1

which is faster than

$x++

If vs Select

Both are close enough in speed that you should use the one that reads the easiest.

Loop vs Iterate

Loops are faster than iterates.

Iterate Var

These are the same for speed:

var:'x' = string; 
iterate: $somearray, $x;

vs.

iterate: $somearray, var:'x';

Reusing Response_FilePath

If you lookup values like Response_FilePath it's better to set it to a var initially and use the var further on.

loop(1000);
	(response_filepath == true ? '' | '');
/loop;

--> 12-14 millisec

var('mypath' = response_filepath);
loop(1000);
	($mypath == true ? '' | '');
/loop;

--> 2-3 millisec

Var Name Length

Short var names are slightly faster than long var names. The shorter the var name, the faster it is, so

var:'a'

is faster than

var:'abcdefg'

which is faster than

var:'abcdefghijklmnopqrstuvwxyz'

String Concatenation

$string += 'concats with ';

$string += 'a lot of ';

$string += 'components';

$string += 'like this ';

$string += 'is slightly slower';

$string = 'than it is ' + 'with a bunch of ' + 'pieces ' + 'like this.';

Concatenation for Display in Lassoscript

'

Show stuff '; $likeThis; 'by just using '; $semicolons; 'between pieces

';

Don't use + between the pieces, it is an unnecessary step, and makes Lasso do more work.

Hard Coded Arrays & Maps

If you need an array, array of pairs, a map, or similar data type with a large number of hard coded values, you would of course be tempted to write it all out:

var:'x' = (array: 'California' = 'CA', etc...)

However, similar to string concatenation, it turns out that it is actually faster to do it this way:

var:'x' = (array); 
$x->(insert:'California' = 'CA'); 
$x->(insert: etc....);

Var Declarations

var:
     'define'    = string,
     'multiple'  = array,
     'vars'      = 0,
     'likeThis'  = 0;

That's a few ticks faster than individual var statements. The more vars, the bigger the difference, so it's not so critical for a couple here & there, but if you have big stacks of vars to define, then do it like above. One caveat, you can't reuse the same var in that statement. So this won't work:

var:
    'x' = 10,
    'y' = $x * 2;

Those would have to be two separate var statements.

Var Symbols

Using $x instead of var:'x' is about 10% faster. To use the $x style, predefine vars like those above, it's good style and faster too.

Don't Use ->size > 0

This is fastest for checking if an array is non-empty:

if: $myArray;

This is somewhat slower:

if: $myArray->size;

and this is even slower:

if: $myArray->size > 0;

This method of checking for non-emptyness can be applied to other data types as well, such as strings and maps. For integers and decimals, zero will return false, all other values will return true. You could even apply it to a custom type by implementing a ->size member that returns an integer if appropriate or just a true|false value.

Don't Use ->find:'x' Just to See if Something Exists

These

if: $myArray->find:'x';

// in custom tags if: params->find:'-useOption'

take at least 2x longer than these:

if: $myArray->contains:'x';

// in custom tags if: params->contains:'-useOption'

Maps and arrays can use ->contains, and it is much faster than using find, and way faster if you add a -> size > 0 after the -> find. The -> find tag fetches data, so that takes longer than just checking if something exists which is what -> contains does. Also, the larger the data element you -> find in arrays or maps, the slower it is. The -> contains method is more consistent over varying data sizes.

You'll notice I mentioned ctags. Using -> contains is legit with the params array that ctags have. Same for client_postparams and other such arrays and maps that Lasso creates on its own. Old habits of using -> find should be shed for all these cases.

Includes vs CTags

All code on one page is faster than using ctags. Using pre-loaded ctags is faster than using includes. Including ctags instead of preloading them at startup is the slowest of all. (LP8's on-demand is interesting if you can use it, but it's not friendly to source code organization IMO.) However, all code on one page is not at all suitable to productivity and maintainability, so you have to weigh the architectural advantages of raw speed for the application's benefit over developer productivity. IMO, use an architecture suited to developer productivity and code extensibility and buy more hardware to handle the load. It's cheaper.

As for which tags are faster than others, many Lasso tags are just LDML ctags. Ctags are much slower than "native" tags. You can find which tags are just ctags by looking in the various places where Lasso comes with the source code of its LassoApps. Some of them offer control for complicated tasks, others are simpler and maybe you'd rather just use straight LDML code rather than incur the ctag overhead. Some of the tags have quite a bit of abstraction that you could fine tune in your own ctag for speed in more fixed circumstances. Looping of course is where this is most important. For occassional use, use the standard Lasso tag, but if you find there's a Lasso tag that's just an LDML ctag you're using inside an intensive loop, maybe there's some performance to be gained by replicating that ctag's code natively in your loop. Generic advice to be sure, but it's something to look into for some cases.

Also, LCAPI and LJAPI ctags will likely always be faster than an LDML ctag. So if you have some rather complex ctags that are critical to your speed needs, and that code is not going to change very often, it could be well worth paying someone to write you a C or Java version. I did this for my config file caching system, and it netted a significant speed boost over using LDML for that.

Author: Gregory Willits
Created: 12 Feb 2011
Last Modified: 16 Mar 2011