Andre Guirard wrote a nice interesting piece of document regarding considerations for application development. The document you can download here.
Recently I have asked to write down some ‘best practices’ from a developer perspective. I see a lot of Andre’s writing return in this, also since most of my work was ‘just’ a collection of documents / papers / hints & tips I have collected the past years.
I will wrote some additional performance considerations which I did not find back in Andre’s work:
Use @trim in all translation events for fields type text, this avoids that you later have to use it in view columns
@Trim(@ReplaceSubstring(@ThisValue; @Char(9):@Newline; ” “))
Make sure when using subforms something is written in Globals of the subform, it dus not matter what (Notes only)
Dim loadfaster As Integer
The more subforms you have the more effect code in Globals has.
Don’t use “Print” so much (LotusScript)
Minimize the use of the Print statement when performing actions in long loops. Printing a lot of messages to the status bar or console uses a surprising amount of memory, and it can have a noticible impact on an otherwise fast-running loop. Specifically, the memory used by each Print statement is not released until the entire agent is finished.
Avoid large or complex tables
Large or complex tables can greatly affect the speed with which a form can be rendered (both in the client and in the browser). In particular, avoid tables with a huge number of rows, a lot of nesting, or a large number of hide-when conditions.
For agents: avoid Reader fields when possible
Using Reader fields can slow down all of your document processing code across the board, because the database has to evaluate the reader fields for each document before it can even attempt to do anything with them. This is especially true when the agent signer doesn’t have access to a large number of documents in the database, because the documents that aren’t visible still have to be evaluated before they can be skipped.
Share NotesView References
If you need to use a reference to a view multiple times in your code, get the view only once and share the reference (either using a global or static variable, or by passing a NotesView object as a parameter in functions/subs/methods). Accessing views using getView is a very expensive operation.
Use @Function Agents For Simple Document Modifications
If you just need to modify, add, or delete one or several [non rich-text] fields in all or selected documents in a view, it is much faster to use an agent with simple @Functions (rather than LotusScript or Java) that runs against all or selected documents.
Resize Arrays Infrequently
ReDim your arrays as infrequently as possible. However, if you have to append data to an array quite often, Redim Preserve is MUCH more efficient than many calls to ArrayAppend
Whenever your application is opened, your default view is opened. Always be sure that this is a view that opens quickly.
Use buttons and picklists instead of drop-down lists
In some cases, there are so many drop-down lists, and they’re so large and used so frequently, that the only reasonable solution is to stop using them on the main form. The line of reasoning to use is to ask yourself the following questions:
- How many times will a document be read in its life?
- How many times will a document be edited?
- Of the times it’s edited, how many times will these lookups be required?
Use DigestSearch Method
For searching server-based databases from a Notes client, DigestSearch is twice as fast as any other search method available, outperforming both full-text search and LotusScript’s GetDocumentByKey method. You call DigestSearch using this LotusScript command:
Set doc=FastSearchByKey(db, “searchword”)
Like I said before, this is ‘collected work’ so I take no responsibility if it would not increase performance. See it as food for thought =)