Notes/Domino Fix List
 |  |
| SPR # FBEE5ZSSC3 | Fixed in 6.0.5 release | Regression in 6.5.1 |
Product Area: Designer Technical Area: LotusScript Platform: Cross Platform
Lotus Customer Support APAR: LO02725
SPR# FBEE5ZSSC3 - LotusScript String handling performance (Mid, left, right, len & Instr). With Surrogate Pair (4 Bytes) support in R6, we took a hit in performance. This fix allows a customer to bypass Surrogate pair support using a Notes.ini flag called DisableLSSurrogatePair. False by default, when set to anything but zero it will disable Surrogate Pair support, in so giving us the R5 LS Performance back.
Technote Number: 1176211
Problem:
Changes in how certain LotusScript operations are handled on a Domino 6.x
server might cause scripts to run longer on a Domino 6.x server than on a
Domino 5.x server. There are three areas at this point to focus on when
analyzing LotusScript performance degradation:
1. String Operations
In Notes 6.x, there is a problem with certain string operations in LotusScript,
specifically the Len() and Mid() functions when they are used with long
strings. These functions can appear to take significantly longer to run than
they did in R5. In many cases, this problem will appear when working with text
read in from a text file by the script; however, it can occur with any string.
The problem is noticeable when the function is called iteratively, and worsens
as the length of the string increases.
This issue was reported to Quality Engineering as SPR# FBEE5ZSSC3, and has been
addressed in Notes/Domino 6.5.4 and 6.0.5.
Excerpt from the Lotus Notes and Domino Release 6.5.4 and 6.0.5 MR fix list
(available at http://www.ibm.com/developerworks/lotus/):
LotusScript
SPR# FBEE5ZSSC3 - LotusScript String handling performance (Mid, left, right,
len & Instr). With Surrogate Pair (4 Bytes) support in 6.x, we took a hit in
performance. This fix allows a customer to bypass Surrogate pair support using
a Notes.ini flag called DisableLSSurrogatePair. False by default, when set to
anything but zero it will disable Surrogate Pair support, in so giving us the
5.x LS Performance back.
Designers are urged to avoid the use of Len() or Mid() iteratively and examine
other possibilities of performing the operations. It may be necessary to switch
to either Formula Language or Java for these operations if they are needed.
2. Script Libraries
New to Notes 6.x is an agent security model in relation to script libraries. In
Notes 5.x, signatures of script libraries were not individually reviewed when
the agent was loaded and all script libraries ran under the authority of the
user who signed the agent. In Notes 6.x, signatures of script libraries are
separately examined. The examination of individual script library signatures is
necessary given that agents can now be signed by one ID but run on behalf of
another user. Note: In the case where an agent is signed by one ID but is
designed to run on behalf of another user, the signer of the script library
must be listed in the Server document's security field titled "Sign Script
Libraries To Run on Behalf of Someone Else".
It is possible that when you have a LotusScript agent that must run very
quickly (for example, a WebQueryOpen or WebQuerySave agent), you could notice a
performance change in Notes 6.x.
The functionality to read script library signatures works as intended. If agent
load time is critical in these types of scripts, Lotus recommends placing all
of the code in a single agent and not utilizing script libraries..
Typical scheduled LotusScript agents should not need any changes, as the minor
performance difference should not affect scheduled agents.
For more information on this issue refer to document, "Agents with numerous
Script Libraries load slower in Domino 6" (#1108765).
3. General Performance
You may notice that some LotusScript code ran quicker under Notes 5.x than
under Notes 6.x. This issue has been reported to in SPR# ADSA5WPLDV. For more
information on this topic, refer to document "Some LotusScript code may run
slower under Notes 6.x than under Notes 5.x" (#1176243). More >
Last Modified on 12/06/2013
Go back
|