Performance tips from the experts
If your web apps are slow, nobody will want to use them. It is as simple as that.
Capabilities such as adaptive filtering, lazy rendering, and of course the architecture of SmartClient mean that if you have selected our platform, you’ve already put your best foot forward. But, of course, taking a wrong turn during development can still quickly degrade performance.
I asked a few of our developers here at Isomorphic to tell us about pitfalls they’ve seen customers hit, how best to avoid them, and to give us any helpful performance tips. Here’s what they said:
Top tips
Mae: Using load on demand for a large data set makes a huge difference. This is enabled by default on the ListGrid (set dataPageSize: “paged”) and the “page” (number of rows fetched at a time) size can be customized using the dataPageSize property.
Charles: Use the FileLoader to start loading the core SmartClient runtime in the background while your users are interacting with a non-SmartGWT login page or landing page, to reduce application load time for first-time users who have not yet cached these files. To do this, load the ISC_FileLoader.js file in your plain HTML login or landing page, and call isc.FileLoader.cacheISC(). Refer to the SmartClient Reference for FileLoader for details of how to get this right (setting path to the files to load, etc), and also to learn about other features of the FileLoader that can help you cache other resources.
An alternative approach is to use <script> tags with the
defer attribute to load all the files of the SmartClient runtime into the current page, without blocking rendering of plain HTML content such as a login form.For an even better experience, identify multiple pages that an end user may visit before they first launch your application, and use the FileLoader to start caching on each of those pages.
Dave: One I’ve run into a few times is aggregating data on the client. It is easy to put together simple DataSources for CRUD data access but there are times where aggregation or computed results are needed. Using the CRUD DataSources works fine for small amounts of data but when the data gets larger the delay becomes a UX failure. Using advanced DataSource joins and possibly creating a read-only DataSource is one way to go. For more complex cases I have created custom SQLDataSource classes that perform the operations server-side and therefore has quick access to related data and can return only the data needed by the client for display.
Greg: Customers sometimes redraw nested widget hierarchies too much, and we tell them to use markForRedraw() to batch those. We also recommend making the DataBoundComponent page size large enough to cover the visible rows.
Jay: A couple of pieces of advice spring to mind:
1) don’t fiddle with data defaults unless you know what you’re doing – the defaults already provide efficiency and scalability in data round-tripping/UI, the bulk of most systems
2) when coding, avoid using Array methods like contains() and find() where possible, particularly in loops – they’re costly methods and become more so with array size
Alex: Two tips I find make a big difference are:
1) Disable autoDraw and explicitly draw only the outermost container to avoid repeatedly redrawing components as the UI is assembled into its final state.
2) If using JDBC connections (via hibernate, JPA, or direct), make sure the connections are pooled. At high load/scale, this makes a huge difference.
The following documentation links may also help:Â Network performance, Smart architecture
We hope this gives you some useful pointers.
How about you?
Have you got a top tip you’d like to share? If so, please email us and we’ll feature on a future blog.
Need help?
If you want help with performance issues, an architecture review, or other, contact us to learn how we can help.
Thanks for reading!
The Isomorphic Team
SaveSave
