For an array A, A.push(b) is more expensive than A[A.length] = b, which in turn is more expensive than A[i] = b (i.e., if you already had the current length of the array in a variable).

Allocating an array in advance, when you know how many elements it will eventually hold, makes no difference on existing runtime platforms, because arrays are just objects that maintain a length field.

Note that if you do not need to know how many elements are in the array, using an object can be slightly more efficient, because it does not have to maintain the lenght field.

The example below illustrates the various ways of adding elements to an array.

Example 41.4. Adding elements to an Array

  <canvas height="150">
    <include href="utils/performance" />
    <script>
      var iterations = Measurement.defaultIterations;
      var textIndexes={};
      for (var i = 0; i &lt; iterations; i++) {
        textIndexes[i] = i.toString();
      }

      function empty () {
        var testArray = [];
        for (var j in textIndexes ) {
          ;
        }
      }

      function measurePush () {
        var testArray = [];
        for (var j in textIndexes ) {
          testArray.push(j);
        }
      }

      function measureSetAtLength () {
        var testArray = [];
        for (var j in textIndexes) {
          testArray[testArray.length] = j;
        }
      }

      function measureSetAtIndex () {
        var testArray = [];
        for (var j in textIndexes) {
          testArray[j] = j;
        }
      }

      function measureSetAtIndexPreallocated () {
        var testArray = new Array(iterations);
        for (var j in textIndexes) {
          testArray[j] = j;
        }
      }

      function measureObjectSetAtIndex () {
        var testObject = {};
        for (var j in textIndexes) {
          testObject[j] = j;
        }
      }

      (new Measurement({'Array.push': measurePush,
                        'Array[Array.length] =': measureSetAtLength,
                        'Array[index] =':  measureSetAtIndex,
                        'Array[index] = (preallocated)':
                        measureSetAtIndexPreallocated,
                        'Object[key] =': measureObjectSetAtIndex,
                        'empty': empty})).run();
    </script>
  </canvas>

In older players, while loops are slightly more efficient than for ... in loops which are slightly more efficent than for loops. The difference is not enough that you should contort your code, but if any will work equally well, you should choose accordingly.

Example 41.5. Iterating with for, for in, or while

  <canvas height="150">
    <include href="utils/performance" />
    <script>
      var iterations = Measurement.defaultIterations;
      var testIndexes={};
      for (var i = 0; i &lt; iterations; i++) {
        testIndexes[i] = i.toString();
      }

      function empty () {
      }

      function measureFor () {
        for (var j = 0; j &lt; iterations; j++ ) {
          testIndexes[j];
        }
      }

      function measureForIn () {
        for (var j in testIndexes ) {
          testIndexes[j];
        }
      }

      function measureWhile () {
        var j = 0;
        while (j &lt; iterations) {
          testIndexes[j++];
        }
      }

      (new Measurement({'for': measureFor,
                        'for in': measureForIn,
                        'while':  measureWhile,
                        'empty': empty})).run();
    </script>
  </canvas>

Using a cascade of if statements is slightly more efficient that using the equivalent logical operators. This is a bug that will be fixed in a future release, so you should not contort your code unless absolutely necessary.

Example 41.6. Conditionals vs. logical operators

  <canvas height="150">
    <include href="utils/performance" />
    <script>
      var iterations = Measurement.defaultIterations;
      var a = false;
      var b = true;
      var c = true;
      function empty () {
        for (var i = 0; i &lt; iterations; i++) {
          if (a == false) {};
        }
      }

      function measureLogicalAnd () {
        for (var i = 0; i &lt; iterations; i++) {
          if (a &amp;&amp; b &amp;&amp; c) {}
        }
      }

      function measureIfProduct () {
        for (var i = 0; i &lt; iterations; i++) {
          if (a) {
            if (b) {
              if (c) {}
            }
          }
        }
      }

      var d = true;
      var e = false;
      var f = false;
      function measureLogicalOr () {
        for (var i = 0; i &lt; iterations; i++) {
          if (d || e || f) {}
        }
      }

      function measureIfSum () {
        for (var i = 0; i &lt; iterations; i++) {
          if (c) {}
          else if(d) {}
          else if (e) {}
        }
      }

      (new Measurement({'Logical And': measureLogicalAnd,
                        'If Product': measureIfProduct,
                        'Logical OR':  measureLogicalOr,
                        'If Sum': measureIfSum,
                        'empty': empty})).run();
    </script>
  </canvas>

The use of with does not appear to affect performance, so it is a stylistic choice.

Example 41.7. with (this) vs. this.

  <canvas height="150">
    <include href="utils/performance" />
    <script>
      var iterations = Measurement.defaultIterations;
      var testObj = {a: 1, b: 2, c: 3, d: 4, e: 5, f: 6};

      function e () {
        return 0;
      }
      function empty () {
        for (var i = 0; i &lt; iterations; i++) 
          e.call(testObj);
      }

      function withThis () {
        with (this) {return a + b + c + d + e + f};
      } 
      function measureWithThis () {
        for (var i = 0; i &lt; iterations; i++) 
          withThis.call(testObj);
      }

      function thisDot () {
        return this.a + this.b + this.c + this.d + this.e + this.f;
      }
      function measureThisDot () {
        for (var i = 0; i &lt; iterations; i++) 
          thisDot.call(testObj);
      }

      (new Measurement({'with (this)': measureWithThis,
                          'this.': measureThisDot,
                          'empty': empty})).run();
    </script>
  </canvas>

The cost of a function call is about equivalent to three assignment statements, so modularizing your code using function calls is not going to create a big performance penalty. Each argument passed to a function call is about equvalent to an aditional assignment.

Example 41.8. The cost of a function call.

  <canvas height="200">
    <include href="utils/performance" />
    <script>
      var iterations = Measurement.defaultIterations;
      var x;

      function empty () {
        for (var i = 0; i &lt; iterations; i++) 
          ;
      }

      function measureAssignment () {
        for (var i = 0; i &lt; iterations; i++) 
          x = 0;
      }

      function eff () {
        return 0;
      }
      function measureFunctionCall () {
        for (var i = 0; i &lt; iterations; i++) 
          eff();
      }

      function gee (a) {
        return 0;
      }
      function measureFunctionCallWithOneParameter () {
        for (var i = 0; i &lt; iterations; i++) 
          gee(1);
      }

      function ache (a, b) {
        return 0;
      }
      function measureFunctionCallWithTwoParameters () {
        for (var i = 0; i &lt; iterations; i++) 
          ache(1, 2);
      }

      function eye (a, b, c) {
        return 0;
      }
      function measureFunctionCallWithThreeParameters () {
        for (var i = 0; i &lt; iterations; i++) 
          eye(1,2,3);
      }

      function jay (a, b, c, d) {
        return 0;
      }
      function measureFunctionCallWithFourParameters () {
        for (var i = 0; i &lt; iterations; i++) 
          jay(1,2,3,4);
      }

      function MyObj () {}
      MyObj.prototype.eff = eff;
      MyObj.prototype.gee = gee;

      var myObj = new MyObj();
      function measurePrototypeMethodCall () {
        for (var i = 0; i &lt; iterations; i++) 
          myObj.eff();
      }
      function measurePrototypeMethodCallWithOneParameter () {
        for (var i = 0; i &lt; iterations; i++) 
          myObj.gee(1, 2, 3, 4, 5, 6);
      }

      var obj = {};
      obj.f = eff;
      obj.g = gee;
      function measureMethodCall () {
        for (var i = 0; i &lt; iterations; i++) 
          myObj.eff();
      }
      function measureMethodCallWithOneParameter () {
        for (var i = 0; i &lt; iterations; i++) 
          myObj.gee(1);
      }

      (new Measurement({'assignment': measureAssignment,
                        'function call': measureFunctionCall,
                        'function call with 1 parameter': measureFunctionCallWithOneParameter,
                        'function call with 2 parameters': measureFunctionCallWithTwoParameters,
                        'function call with 3 parameters': measureFunctionCallWithThreeParameters,
                        'function call with 4 parameters': measureFunctionCallWithFourParameters,
                        'method call': measureMethodCall,
                        'method call with 1 parameter': measureMethodCallWithOneParameter,
                        'prototype method call': measurePrototypeMethodCall,
                        'prototype method call with 1 parameter': measurePrototypeMethodCallWithOneParameter,
                        'empty': empty})).run();
    </script>
  </canvas>

It's always a good idea to carefully examine inner loops (loops that are central to an algorithm and executed many times) for expressions that don't vary with the loop index and move them out of the loop. This is just good standard programming practice, but it may not be quite so obvious in an object-oriented language such as Javascript.

The example below shows how accessing a deeply nested element of a object heirarchy is really a constant expression that can be moved out of a loop.

Example 41.9. Moving constant expressions out of a loop.

  <canvas height="150">
    <include href="utils/performance" />
    <script>
      var iterations = Measurement.defaultIterations;
      var x;

      function empty () {
        for (var i = 0; i &lt; iterations; i++) 
          ;
      }

      var myObj = { a: 'eh?', b: 'be',
                    c: { d: 'dee',
                         e: { f: 'eff',
                              g: { h: 'ache'}}}}

      function measureHardWay () {
        var ans;
        for (var i = 0; i &lt; iterations; i++) {
          ans = a.c.e.g.h;
        }
      }

      function measureEasyWay () {
        var ans;
        var aceg = a.c.e.g;
        for (var i = 0; i &lt; iterations; i++) {
          ans = aceg.h;
        }
      }

      (new Measurement({'in the loop': measureHardWay,
                        'out of the loop': measureEasyWay,
                        'empty': empty})).run();
    </script>
  </canvas>

If you will have more items in your list than will appear to the user, you should use dataoption="lazy". In this case the listitem will use lazy replication and the list will use a LzDataSelectionManager, instead of a LzSelectionManager. Some of the APIs for adding and removing items will not be available, but startup time will be significantly faster. In general, you can modify data through the data APIs instead of using list methods. If you have created your own listitem class you can use the LzDatapath replication attribute.

In the example below, only four textlistitem views are created, even though there are ten items in the dataset.

	Note
	If you declare a <textlistitem> with a child <datapath> , you must set datareplication="lazy" on the <datapath> element if you set dataoption="lazy" in the list. If you are using a datapath attribute, that happens automatically.)

<canvas width="200" height="120">
  <dataset name="mydata">
    <numbers>
      <option name="first"/>
      <option name="second"/>
      <option name="third"/>
      <option name="fourth"/>
      <option name="fifth"/>
      <option name="sixth"/>
      <option name="seventh"/>
      <option name="eigth"/>
      <option name="ninth"/>
      <option name="tenth"/>
    </numbers>
  </dataset>
  <list id="mylist" shownitems="4" dataoption="lazy">
    <textlistitem datapath="mydata:/numbers/option/@name"/>
  </list>
  <text text="${mylist.value}"/>
  <simplelayout spacing="4" inset="10"/>
  <constantlayout value="10" axis="x"/>
</canvas>

The developer console displays the uncompressed and gzipped size of the application. The gzipped size is the size that will be transferred to most browser clients; it is proportional to the file transfer time. The uncompressed size is the size that will appear in the browser cache, or if you use a tool such as curl or wget to retrieve the file.

The developer console also contains a link to the size profile for the application. This page displays size statistics particular to the application. These statistics are relative to the uncompressed size of the application, not the compressed size, but they are still a useful tool in finding the "size hot spots" of your application.

Changing embedded datasets and resources to requested datasets and resources will reduce the initial download size of the application. If these assets are only used in some execution paths, th this will also reduce the total download size of the application, for use cases that avoid these execution paths.

In general, you do not have to worry about the resources consumed by creating views. However,if you have an application that creates a large number of views, you may want to use the destroy() to free memory.

You would not need to use destroy if a view could only be referenced by one variable. Because views can be referenced in many ways (e.g., name, id, events, delegates, handlers) destroy can be used to 'detach' a view from all these links so that it can be garbage-collected. destroy should not be needed in simple programs or programs that are built from Laszlo components.

When tracking down memory usage, replicated views are a good place to look. When you make more than one copy of a view, you will use proportionally more memory. So when performance tuning, remember that $path is implicated in replication.

Note that constraints do not consume large amounts of memory. $once and $always are equivalent in memory usage, but clearly $always will require more cpu.

Constraints are an extremely useful way to nicely lay out an application. They are conceptually elegant, allow for writing compact maintainable programs, and help with rapid application development. Constraints are so incredibly tasty for rapid prototyping. However, they can be expensive in terms of performance.

The significant contributions to the cost of constraints aren't so much in the evaluation of the constraint expression itself. Rather, they come about from two causes:

Therefore it is sometimes helpful to replace constraints by explicitly setting attributes and chaining events with delegates. You should do this after the functionality of the program is essentially complete.

Instead of writing

<view id="foo" x="${parent.something}" y="${parent.something}">, 

write the code that changes parent.something to update foo's x and y instead, replacing several function calls and loops through the constraint system by one function call. Too may constraints can make operations, like resizing views and windows, pretty stuttery. Rethinking all those constraints to minimize them and do some programatically by hand can really help in some cases.

The $once technique also helps:

<view name="nugget" width="$once{thingy.width}" ... />

instead of

<view name="nugget" width="${thingy.width}" ... /

This constraint is just evaluated once, when the view's attributes are first set. This will only work for static layouts, of course, and only if instantiation order works right. In this case, thingy must be constructed, and its width attribute must be set, and "thingy" must be in scope, in order for the $once form to work.

Another technique is to write your own "virtual constraints" in a method. This has the effect of reducing the number of method and function calls. The example below positions <code>dotty</code> to sit inside <code>nugget</code> with a padding of 5 pixels on the left and right.

<view name="nugget">
<view name="dotty" .... />
<method name="init">
this.update();
super.init();
....
</method>

<method name="update">
this.setAttribute("width", thingy.width);
this.dotty.setX( 5 );
this.dotty.setAttribute( thingy.width - 10 );
...
</method>

<!-- Update positioning whenever thingy's width changes -->
<method event="onwidth" target="thingy">
this.update();
</method>
....
</view>

Compare the above to:

<view name="nugget" width="${thingy.width}">
<view name="dotty" x="5" width="${thingy.width - 10}">
...
</view>
...
</view>

The second form is much more compact and readable, but the first form uses zero constraints. The call <method event="onwidth" target="thingy"> is nearly a constraint on thingy.width, but: in the explicit-update form, one thingy.onwidth event can trigger a single call to update which, which will end up doing the repositioning that otherwise would require at least a handful of constraints. Like constraints, method calls are expensive. So, fewer constraints, fewer method calls, faster performance.

You may, in some limited circumstances, gain a performance boost by assinging attribute valutes instead of setting them using a setter, (preferably, the setAttribute() method). In general, using object.setAttribute('attr', value); to set an attribute is the best way to set attributes, as explained in Chapter 29, Methods, Events, Handlers, and Attributes.

For speed, however, you may sometimes use a direct assignment, as in object.attr = value;. When you do this, you need to be aware that no events are generated, and you are giving up the chance for any dependency that refers to object.attr to update. Use this technique with caution and only if you are sure that you have handled any dependencies. As we have heard said at Laszlo Systems, it's like overclocking your motherboard. You can do it if you think you know what you're doing, but don't blame us if your machine catches on fire. (Your machine won't literaly catch on fire, of course, but your application may fail spectacularly!)

The server-side configuration is different for different servlet containers and web servers. The idea is to tell whatever application responds to HTTP requests that it should compress JavaScript before sending it. We expect our users to deploy to a variety of servlet containers and web servers, so, instructions on how to configure a particular system to gzip JavaScript are beyond the scope of this document. We recommend that deployers do do this configuration. As an example, for tomcat, one would add attributes about compression to the connector tag in your server.xml:

<Connector port="8080"
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/JavaScript,application/x-JavaScript,application/JavaScript"/>

The client-side configuration is much easier; the HTTP protocol specifies "content codings" which may include gzip. A properly configured server will add the appropriate content-coding=gzip header, and modern browsers will recognize that that header means that the content will be gzipped. With todays browsers (including all browsers supported by OL4), this does not require any client-side (browser) configuration.