Profiling of LotusScript agents has been something that can be enabled for some time and I’ve long been a fan of it, blogging about it in 2011. Profiling was also something built into XPages Toolbox by Phil Riand. It’s also something I’ve built into RADAAR and my OSGi plugins in Java – just a simple Java timer function that logs to OpenLog. It’s helped identify bottlenecks in code and identify bugs where I’ve looped more than anticipated.
When I got my hands on the Domino V10 beta, I started applying new methods to ODA and cross-referencing with LotusScript to work out what the parameters are. The Java methods typically have parameter names arg0, arg1 etc. But LotusScript gives more usable parameter names, which can often help identify what needs to be passed. While looking at the new NotesSession methods I found three new methods in LotusScript which were not in Java –
NotesSession.getProfileResults(Output as NotesDocument, Title as String). These now allow developers to profile code that’s outside of an agent and save it to a profile document.
Here’s some sample code that iterates all entries in the “AllContacts” view in the Extension Library demo database and updates those whose state is Arizona. The profiler is started before the iteration and stopped at the end., and the results are stored in a new profile document withthetitle “Test Profiler”.
The profile document created is the same kind of one that the agent profiler creates. The Form name is “$BEProfileR7”, the subject is the string title passed into the
getProfilerResults() method and the body is the profile results. I haven’t worked out how to open the document yet. Obviously when you open the profile results by right-clicking an agent it somehow opens in that Form, which must be held somewhere in Notes. But opening the created document seems to expect that Form to be part of the design of the NSF which, obviously it isn’t. Hopefully someone can shed some light on that.