• Home
• Platform
• Download
• Documentation
• Community
• Wiki
• Blog

From OpenLaszlo

Also see the Performance chapter in the Developer's guide. This page collects more recent tips and community discussion.

Contents 1 Measure startup time 2 For string operations, use split and join 3 Delegates are faster than closures 4 Deferring instantiation of datasets 5 Skanky Hacks 5.1 Rewrite to avoid constraints 5.2 Replace setAttribute by assignment 6 Forum Threads 6.1 Performance Tips

Measure startup time

   <!-- This little bit of code puts a white box in the top left corner
         that gives time to app init in milliseconds.-->
    <view name="inittime" bgcolor="white" visible="true" >
        <method event="oninit" reference="canvas">
            var d = new LzDelegate( mytext , "tellTime" );
            LzIdle.callOnIdle( d );
            this.bringToFront();
        </method>
        <text id="mytext" resize="true">
            <method name="tellTime" args="t">
                this.setText( "Time taken: " + t );
            </method>
        </text>
    </view>

For string operations, use split and join

Method calls are stupidly expensive in the Flash Player. Split and join are your friends. For example, to remove all the spaces in a string, it's fast to do this:

  var noSpaceString = origString.split(" ").join("");

Delegates are faster than closures

Tucker: I just measured the storage used by a delegate vs. using a closure -- since I speculated once that might help; but delegates win handily:

 delegate   715
 closure   2529

(I guess closures must just copy their entire environment, rather than just the free variables they close over? Gee, the Flash player has a lot of room for improvement!)

Deferring instantiation of datasets

Place dataset(s) inside a <state> and apply it when you need the dataset(s). For example:

<canvas>

  <method event="oninit">
    // instantiate dataset after application is fully inited
    canvas.deferdsets.apply()
  </method>

  <state name="deferdsets">
    <dataset name="foo">
    ...
    </dataset>
    <dataset name="bar">
    ...
    </dataset>
  </state>

</canvas>

You can also put a local dataset in a view and defer instantiation there.

Skanky Hacks

These are not best practice for readability or maintainability, but they can help performance. If you're old enough, you can think of it as the equivalent to adding 'register' declarations or unrolling loops in your C program.

Rewrite to avoid constraints

Rewrite slow code to avoid the constraint mechanism. Instead of writing <view id="foo" x="${parent.something}" y="${parent.something}">, they'll 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.

Replace setAttribute by assignment

Replace object.setAttribute('name', value) by object.name = value. This avoids a function call and the event system. Chris K has written a post.

Above one not properly working in some situation eg:

canvas.buildpagealert.setAttribute('text',monthstr);

canvas.buildpagealert.text=monthstr;

these above not working then how can improve performance.

thank and regards raju samala

Forum Threads

Performance Tips

In this thread [1] , you can make threaded and email-supervised contributions.

The following tips are taken from this blog post:

• When using constraints, use $once{} as often as possible - Constraints are a great time saver, but they come at a cost. Normal constraints have to have their events registered when the application starts up, so if you have a lot of constraints, this can slow things down. If you don't need the constraint to update after application startup, use $once{} for an incremental performance improvement.
• Use short variable names - I believe this was more of an issue with older versions of the Flash player, so I'm not sure how relevant this is, but it is my understanding that because of the nature of Javascript, long variable names actually have a negative performance impact. If you look at any of the Laszlo run time source code, you'll see most of the variable names are VERY short, to the point that it makes the code hard to read.
• Use pooling and lazy replication for replicated views as often as possible - Take advantage of the hard work Adam put into making these features work. Pooling reuses previously replicated views, improving the rendering time when a datapath is updated. Lazy replication only replicates the visible views, hence saving lots of time in the event you have a scrolling list of say hundreds of replicated nodes. You'll likely need to tweak your code to get these two features to work, but the performance gain you get is totally worth it.
• Minimize the number of views used - Views are expensive to instantiate, so do what you can to minimize the number of views generated. Focus on classes that are constructed often via replication or other means. For example, in our diagram editor every shape contains 'connection points' which are represented by little '+' symbols. Originally, we created the '+' with two views (one horizontal, and one vertical). By using a single asset for the '+' symbol, we cut the number of constructed views down substantially for each shape, yielding faster diagram load times.
• Load images at run-time - If you don't need to display an image right away, consider loading the image at run time to reduce the initial application download size.
• Delay instantiation - Delay instantiation on any views that wont be shown right away to improve start-up performance. For example pop up windows, drop down menus, etc.
• Use local variables when possible - I think this is another issue that is less important with the newer Flash players, but probably worth looking into. Apparently accessing global variables can be slow, so you're better off creating a local reference to the global variable if you are going to access it a bunch in a loop.