ExoWeb performance considerations
Bryan Matthews
I have recently done a review of performance in a couple of apps that use ExoWeb, and here are some things that I’ve found. The gist of it is that template rendering and other UI-related code tend to be the biggest problems.
1. Most people are already doing this. For your initial page load it is faster to embed the data in the page, rather than create queries on the client and then call back to the server.
2. Avoid numerous and complex property calculations.
Disclaimer: client-side property calculations are typically only very expensive if they involve very large numbers of objects*, or (more likely) the calculations have an impact on template rendering.
* For example, if you have a rule that depends on a chain involving type Foo, and there are 1k Foos on the client, this can have a noticeable impact.
3. Avoid calling jQuery.issues({ refresh: true }), especially on large pages, since this will cause all relevant rules for every bound field to run, regardless of whether it needs to. Moving forward this should not be necessary. For now, it may be necessary to ensure that rules run for objects that are created on the client and their property has not be interacted with. An alternative in this case is jQuery.issues({ ensure: true }) which will only attempt to run rules which have not be run previously. I hope to eliminate the need for this entirely.
4. Try to limit the number of selectors that you register with “ever”. It’s a great tool that you probably wouldn’t want to do without, but should be used judiciously. The reason for this is that the selectors must be processed each time content in templates is added, removed, or updated. The number of selectors has a significant impact on how fast this processing can occur. To a lesser extent, the efficiency of the selectors can have an impact as well.
· Avoid large numbers of dynamic calls to ever and prefer to make a single ever registration when possible. If you’re not calling ever dynamically then this doesn’t apply to you.
· For one-off scenarios, like an event handler on an element that only shows up in one place, avoid using ever and embed the event handler in the markup instead. Ever is best suited for applying styling or behavior to a class of elements that could show up in different places (i.e. a datepicker control).
5. When setting a property value in the model which will cause a template (dataview, content, etc.) to render, try to perform any manipulation of the object (and related objects) prior to setting the property. Setting the property and then manipulating the objects could result in extra work in template rendering, since the template(s) will be rendered initially and then update in response to your model changes.
6. When rendering a page or dialog with multiple regions of content that will be hidden initially, use the render/dispose behavior of toggle rather than just hiding the element in the DOM. There may be cases where you want to render everything up front so that the user experience is faster afterwards, especially if the user is not currently interacting with the page, but if the user is interacting with the page then hiding regions of the page that are still rendered will result in longer wait times than necessary.
These are just guidelines obviously. I will try to send out updates as I encounter more problem scenarios. Or course let me know if you have questions about any of these.