Are LotusScript Libraries Slowing Down Your Views?
One of the primary goals of any IT organization is delivering applications that improve the efficiency of business processes. As application developers, we can have tremendous impact on the day-to-day running of the business. Few things will generate user feedback more quickly than poor application performance. So with that in mind, I'd like to share some techniques for improving user experience that came up recently when troubleshooting some very slow views and view actions.
Optimizing Views is important, complex topic. There are a lot of great performance tips out there that address View performance and recommend best practices for designing Views. (more)
Optimizing Views is important, complex topic. There are a lot of great performance tips out there that address View performance and recommend best practices for designing Views. (more)
Sometimes, however, a View that does not have any typical indexing-performance issues is still slow to load. Take for example a View in a local database with less than 500 documents that consistently takes more than ten seconds to load... I don't know if there's any lousy combination of "@Today" selections, complex formulas, and reader fields that can alone cause this kind of performance.
So today's topic is really a sideline to View performance: the performance cost of loading LotusScript Script Libraries, because they can cause that kind of performance issue. And you might not think to look there if you were working with a much larger database that potentially does have View-related performance issues.
I am going to split this topic into two posts: today's post explores the common but useful technique of using an agent to defer script library loading until it's needed, and the next post will examine the concept of "Dynamic Script Library Loading" from the perspective of user-experience. Both techniques can also be applied to forms and any other UI component that can load script libraries.
Before I start, I should note that some time ago Craig Schumann posted a blog entry on Option Declare and compiling (or lack thereof) of Shared Actions--which had some drastic effects on the performance of loading Views where the shared actions were used. If you're using shared actions, you should read it--and check out the free utility he provided to help you identify such problems.
So the issue: you have one script library that contains functions triggered from a View. It's perhaps not large, but it has "Use" statements in the Options section for lots of other libraries, that may total megabytes worth of data in a complex application:
Each of those libraries may include a bunch more libraries. Now your View (or the actions, shared or not) in the View include a "Use" statement that loads the original library, and cause the whole chain of libraries to load before the View can display. This happens not once per session, but every time the user switches to that View.
The solution is easy: don't put that "Use" statement in the View. Instead, put it in an agent, and call the agent from the View (@Command([RunAgent]), or LotusScript, what have you). Now the View loads without the libraries, and the libraries only load if the user actually invokes the UI action.
This is common practice amongst developers that have encountered the problem, but I think it's worthwhile to point it out. I've used this technique for years, but when it comes to Views, I still get tricked sometimes, wondering what is causing a View to load so slowly.
I've documented some performance tests below to illustrate how significant this delay can be. To help get an accurate measure of the load time, I've created some agents that simply open the front-end View via the NotesUIDatabase object:
Because the function doesn't return until the UI View finishes opening, I can now time each function in Profiler to track how long it takes:
Notice that where the "Use" statement was in a shared action included in the View (as per the function names), the View takes almost 14 seconds to load. Obviously, when externalized to the agent it takes almost no time.
I have run the test a couple dozen times, in different orders, and got the same results repeatedly. Here is how the functions averaged after 11 runs, keeping the database open the whole time:
So by simply moving the library loading to an agent, we defer this rather large wait until someone actually needs to run the function, and the View appears snappy, opening in a fraction of a second. The test results here are rather extreme--I am using a very complex application that employs dozens of script libraries. For a typical application this delay might only be a few seconds. But for the end user, eliminating even a small delay makes an application feel faster and improves the user's experience.
In the next post, I'll illustrate a more advanced topic: how dynamic script loading can further improve the user's perception of the speed by deferring code loading until the appropriate moment in execution.
So today's topic is really a sideline to View performance: the performance cost of loading LotusScript Script Libraries, because they can cause that kind of performance issue. And you might not think to look there if you were working with a much larger database that potentially does have View-related performance issues.
I am going to split this topic into two posts: today's post explores the common but useful technique of using an agent to defer script library loading until it's needed, and the next post will examine the concept of "Dynamic Script Library Loading" from the perspective of user-experience. Both techniques can also be applied to forms and any other UI component that can load script libraries.
Before I start, I should note that some time ago Craig Schumann posted a blog entry on Option Declare and compiling (or lack thereof) of Shared Actions--which had some drastic effects on the performance of loading Views where the shared actions were used. If you're using shared actions, you should read it--and check out the free utility he provided to help you identify such problems.
So the issue: you have one script library that contains functions triggered from a View. It's perhaps not large, but it has "Use" statements in the Options section for lots of other libraries, that may total megabytes worth of data in a complex application:
Each of those libraries may include a bunch more libraries. Now your View (or the actions, shared or not) in the View include a "Use" statement that loads the original library, and cause the whole chain of libraries to load before the View can display. This happens not once per session, but every time the user switches to that View.
The solution is easy: don't put that "Use" statement in the View. Instead, put it in an agent, and call the agent from the View (@Command([RunAgent]), or LotusScript, what have you). Now the View loads without the libraries, and the libraries only load if the user actually invokes the UI action.
This is common practice amongst developers that have encountered the problem, but I think it's worthwhile to point it out. I've used this technique for years, but when it comes to Views, I still get tricked sometimes, wondering what is causing a View to load so slowly.
I've documented some performance tests below to illustrate how significant this delay can be. To help get an accurate measure of the load time, I've created some agents that simply open the front-end View via the NotesUIDatabase object:
Because the function doesn't return until the UI View finishes opening, I can now time each function in Profiler to track how long it takes:
Notice that where the "Use" statement was in a shared action included in the View (as per the function names), the View takes almost 14 seconds to load. Obviously, when externalized to the agent it takes almost no time.
I have run the test a couple dozen times, in different orders, and got the same results repeatedly. Here is how the functions averaged after 11 runs, keeping the database open the whole time:
So by simply moving the library loading to an agent, we defer this rather large wait until someone actually needs to run the function, and the View appears snappy, opening in a fraction of a second. The test results here are rather extreme--I am using a very complex application that employs dozens of script libraries. For a typical application this delay might only be a few seconds. But for the end user, eliminating even a small delay makes an application feel faster and improves the user's experience.
In the next post, I'll illustrate a more advanced topic: how dynamic script loading can further improve the user's perception of the speed by deferring code loading until the appropriate moment in execution.
Category Coding Practices
| Permalink |
|
|
|
|
|
