I've blogged before about VariableResolvers and the more I dig into them, the more powerful they are. Performance-wise, I've already blogged they're as rapid as you can get, the perfect place for regularly-accessed bits of code. Anyone at UKLUG will have seen that I extended that particular performance table to show that a VariableResolver in an OSGi plugin is virtually as quick. But there is a caveat I've found. Amusingly, I'd made the link that examines the caveat on another blog post, about Expression Language. I said: Expression Language is parsed quickly. I suspect it’s using something like a ...
A little over two years ago I blogged about the different languages available in XPages, namely Expression Language, Server-Side JavaScript and Custom. I explained what Custom was and how it could be used. Bearing in mind that XPages are compiled down to Java code, with each control being a class, it makes sense that the fewer controls you can use, the better for performance. Evidence bears out that hypothesis, as I will be showing at UKLUG next month. Furthermore, of the three, Server-Side JavaScript performs worst. Literal strings don't need passing to a parser, and Expression Language is parsed ...
As I have often said, one of the things I like about XPages is that you can always learn more and enhance your skills. The learning curve is steep at times, but there are aspects you can add on at a later stage. One of those is VariableResolvers. Like so many Java constructs, the terminology is alien to traditional Domino developers - and I place myself in that category too. So what does it mean? Basically, you pass in a variable name as a String and the VariableResolver returns some kind of result - a String, a Boolean, an object of ...
One of my sessions for BLUG, The Eureka Moment: The JSF Knowledge You Need To Understand XPages, has led me to investigate XPages optimisation and partial refresh processing to an extent I haven't in the past. Much of the evidence gained has been illuminating for me too and has given me an understanding which will make me and my team think more when developing our XPages applications in the future. The JSF lifecycle and its quirks, seems to be a topic more developers have been delving into recently or hitting the impacts of: Tony McGuckin has posted an XSnippet ...
Earlier this week I picked up a tweet from Alan Hamilton about an IBM whitepaper about how to optimise performance of the Notes Client. Not surprisingly, the operating system has a big impact on the speed of Lotus Notes opening, but also hanging of the Notes Client (and presumably Domino Designer client). The whitepaper is well worth reading, particularly for support teams. Good management of the PC can avoid some of frustrations of users that are wrongly laid at the feet of Lotus Notes. Any developer providing an application on ...
Agent profiling is not new in Domino, but it's something that gets little press. Because it's only available for agents, it's probably also going to become less useful as more and more development is done in XPages. But, working from the premise that the methods in use in LotusScript do the same work on the whole as their Java counterparts, best practices learned from LotusScript are equally applicable to XPages development. Over the last year there have been countless articles about the performance of NotesViewNavigator compared to NotesViewEntryCollections or NotesDocumentCollections. Innocently (or should that be naively), yesterday I wrote some code ...
Autosave database size revisited: it SEEMED like a great idea but…
Just to remind anyone who didn't read my post last week, the gist was that I noticed my autosave database was very large, even though it had no documents in it and rarely had documents in it. The apparent cause was that default Space Savers setting on the Replication Settings was set, so documents were removed after 90 days, and deletion stubs after 30 days. So I made the seemingly obvious step of reducing the duration, so documents were removed after 3 days and deletion stubs would be deleted each day. This seemed a great idea. But all good plans and ...
Autosave database size
Our Domino Administrator noticed today that the as_XXXXX.nsf database was extremely large. This is the database used to store documents and emails if autosave is turned on. Autosave was a new option with R7, if my memory is correct, and although I've never used it for a Form in a database (most forms tend to be quite small), I've found it invaluable on a number of occasions for emails and Symphony documents. Being curious I also had a look at my own as_pwithers.nsf database. It was nearly 400Mb. When I opened the database there were no documents in any of the views, which ...
At the moment I'm reviewing some older databases to look for performance improvements. Some leap from the screen, like changing GetNthDocument for GetFirstDocument and GetNextDocument in script, removing unnecessary sorting, removing private views that had been created for support purposes. Much of what I've been looking at is based on the whitepaper article by Andre Guirard which, if you've never come across it, is a must read. At the moment I'm going through views and comparing the view to the view index size on live. This is throwing up some interesting information. For example, I have one view that ...
Views Related to Current Date
One of the functions I found customers often requesting was a view where something in the view selection formula or column formula required comparison to today's date. But we all know @Today is not recommended in views because of the performance issues. This is a little agent I created to allow me to hard-code a date in a view's selection formula, but update it daily. The view selection formula is e.g. today:=[29/12/2009];SELECT Form="Document" & MarkForDeletion != "1" & LiveRefs = "" & ArchiveDueDate < today & Archived != "1" I use a list to hold the views - alternatively this could ...
