I Feel the Need - The Need for Speed: LotusScript Performance Tuning

By Nigel Cheshire

Like a lot of people, we’re thrilled that the IBM Lotus Notes & Domino platform is getting a lot of attention from IBM and HCL right now. If you’ve been paying attention to the slew of announcements that have been coming out of those two companies recently, you’ll be aware that, from a developer perspective, there are two scripting languages that are in the spotlight right now: JavaScript and LotusScript.

Node.JS support is being added to Domino 10 to allow developers to build applications using JavaScript and Node that can easily access Domino data. That’s great, but for developers who are maintaining older apps, or just want to stay in the Notes (i.e. Domino Designer) environment and don’t necessarily want to learn a whole new way to build applications, it’s great to see that LotusScript is getting some love from HCL. In particular, LotusScript is being extended to add access to mobile device capabilities, such as the camera and GPS, as well as HTTP extensions to web enable LotusScript code.

If you are reading this, then you almost certainly know what LotusScript is. Since version 4.0 of Lotus Notes was released in 1996, LotusScript has been the preferred way of writing code in Notes apps once formula language starts to run out of steam (i.e. for more complex applications).

LotusScript is great, but many of our customers have found it difficult to track down performance problems in their Notes & Domino applications, especially when they include LotusScript. LotusScript agents are often the worst offenders, and server agents in particular are hard to debug and even harder to profile for performance issues. A server based LotusScript agent gumming up that server’s performance can be really hard to resolve.

Here at Teamstudio, we’ve got years of experience with performance profiling. In our (not so) brief flirtation with the Java tools market (under the brand name Enerjy), we built a Java performance profiler back in the early 2000s. So we think we know a thing or two about this subject.

There is some rudimentary support for performance profiling built into Domino, but it’s only available for profiling agents and gives you pretty scant timing info on how long each method took. So you can take some guesses at what is slowing things down within a method, but there’s still a lot of trial and error. And if your performance problem is in the UI, then all bets are off.

That’s why we built Teamstudio Profiler. It’s a full-featured performance profiler for LotusScript that breaks down timings for your LotusScript code line by line and shows the timings in the context of your code. Also, there’s no need for any code changes to run the performance profiler. Turn it on, run your code, turn it off and see the results. That makes it super-easy to use, and there’s no risk of making mistakes when you’re editing code to add or delete timing code.

With the renewed level of interest and investment going into the IBM Lotus Notes and Domino platform, we are expecting to see organizations that are currently supporting older LotusScript applications continue to support them into the future. And with the new additions that are being made to the language, there may even be a renewed interest in building new applications using LotusScript. Either way, tracking down performance problems without a full featured profiling tool like Profiler will continue to be a tough challenge.

As an aside, if you’re an existing Teamstudio customer and you don’t have Profiler, we have some interesting offers available that mean you could get your hands on the product for very little cost. If you’re interested, or just want to talk about any aspect of building or maintaining IBM Lotus Notes and Domino applications, click below. We’re always happy to chat!