[This vs That Syntax Tips for Speed] at tagSwap.net: Open Source Lasso Code

[This vs That Syntax Tips for Speed]

Greg Willits, June 18, 2005

I and others have posted several syntax speed comparisons on LT over the years, but I hadn't consolidated them into a single list. This is an attempt to remember the things I've tested. Some things were tested in LP6, 7, and 8, but I believe they all hold true in LP8 still.

If you have your own tests, email me a description like those below and I'll add them.

Incrementing

$x += 1 is faster than $x++

Select v If

select:case is faster than if:else

Iterate v Loop

Iterates are much faster than loops.

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

is faster than

iterate: $somearray, var:'x';

For LP6 users: if you have multiple arrays to handle in a loop and you use loop_count, it is actually still much faster to do this than it is to use loop and loop_count. Since LP7, you can use loop_count in an iterate, so follow this same idea, of using an iterate for the task, but you can use loop_count instead of $indx.

var:
    'indx' = 0,
    'thisOne' = string;

iterate: $orderLines, $thisOne;

    $indx += 1;

    $price = $orderPrices->get:$indx;

    $qty = $orderQuantities->get:$indx;

Var Name Length

Short var names are in fact faster than long var names.
normalVarName is 20% faster than reallyLongVarNameToTheOftenSeenExtreme

String Concatenation

$string += 'concats with ';

$string += 'a lot of ';

$string += 'components';

$string += 'like this ';

$string += 'is faster with += ';

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

Concatenation for Display in Lassoscript

'<p>Show stuff '; $likeThis; 'by just using '; $semicolons; 'between pieces</p>';

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.

Using Temporary Vars

If you frequently re-use statements like ($array->get:$indx)->first, it is faster to assign that to a var and use the var over & over than it is to keep using the long version over and over. Some people would do that just for readability, but it also faster.

So, instead of

if: ($array->get:$indx)->first == 'H1';

    '<h1>';
 ($array->get:$indx)->second;
 '</h1>';

else: ($array->get:$indx)->first == 'H2';

    '<h2>';
 ($array->get:$indx)->second;
 '</h2>';

else: ($array->get:$indx)->first == 'H3';

    '<h3>';
 ($array->get:$indx)->second;
 '</h3>';

/if;

Do this:

var:'titleType' = ($array->get:$indx)->first;

if: $titleType == 'H1';

    '<h1>';
 ($array->get:$indx)->second;
 '</h1>';

else: $titleType == 'H2';

    '<h2>';
 ($array->get:$indx)->second;
 '</h2>';

else: $titleType == 'H3';

    '<h3>';
 ($array->get:$indx)->second;
 '</h3>';

/if;

Now, why didn't I also do it for the ->second statement? In that code, the ->first syntax is processed up to three times. But no matter what, the ->second syntax is only processed once, so there is no value to assigning it to a var.

Also, if you're paying attention, you'll notice that this should actually be written using select:case and not if:else, but this is the only example I could think of in a jiffy. There's other ways to optimize this specific example for better maintainability, but I'm just trying to illustrate the one point, so don't get too picky about slamming my example! :-)

Don't Use ->size > 0

This

if: $myArray->size > 0;

takes 2.5x longer than this:

if: $myArray;

That can be applied to integers, strings, arrays, maps, and other data types as well. 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 find 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 and 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.

Updates

Added the ->size tip on Apr 27, 2006.
Added the ->contains tip on June 06, 2006.

[This vs That Syntax Tips for Speed]

Articles