Skip to content
Home ยป Performance

Performance

Lazy code

A best practice for coding involves delaying slow operations until certain they’re needed, then caching the result.

NotesStream performance

Lars Berntrop-Bos posted a comment concerning the LotusScript NotesStream class and his practice of reading as large a block as he possibly could to optimize performance. I decided to run a test to see how much difference that made. The results are as follows: Block size (bytes) Runtime to read a large file (seconds) 512 10.30 1024 5.09 2048 2.75 4096 1.49 8192 0.86 16384 0.52 32768 0.35 65536 0.26 Each of these cases is doing the same amount of work — reading every byte in the same large binary file. The effect of increasing the block size is dramatic — the largest possible block size was 40 times faster than a 512-byte block. 216 bytes is the upper limit of the NotesStream.Read method, because that’s the maximum number of elements in the array datatype… Read More »NotesStream performance

Overhead of error trapping in LotusScript

Having a little fun with the performance monitoring code from a previous post. Okay I have a warped idea of fun. I’m always interested in performance, so I decided to analyze the overhead of using an error trap (On Error statement) to handle edge cases as opposed to an “if” statement or other branch. The error trap is often easier to code because it can be a catch-all for any unanticipated problem, but handling an error condition involves the LotusScript runtime coming up with an error message, determining whether the script has defined special handling for that error, etcetera. So it can be expected to take longer than a simple test and branch. My question was, how much longer? Testing method To test this, I created two subroutines to try the two different approaches: Sub… Read More »Overhead of error trapping in LotusScript

String Functions Performance Considerations

I’ve been doing some tests and I see Instr$ in LotusScript is still a lot slower when you start searching in the middle of the string. I wrote an SPR about this sometime back. The same is true of Mid$ – I wrote a timing test that uses Mid$ to get the 1st character of a string as opposed to the 27000th. The latter takes much longer, and I don’t understand why. According to the help docs it’s two bytes per character, so it should be trivial to determine the location of a character from its number position. Timing test results What’s going on here? How can it take so much longer to access a string starting at a later position? It must be looping to get to the right starting position instead of just… Read More »String Functions Performance Considerations