Feb 10, 2015, 6:06 PM
122 Posts

Recycling

  • Category: Performance
  • Platform: All
  • Release: All
  • Role: Developer
  • Tags: recycle
  • Replies: 3

I'd recommend only recycling in loops. Recycling is because of a limit on the number of concurrent handles to C++ objects in a single request. The limit is over 20,000 for a Windows 9.0.x server. Five different variables pointing to the same underlying Domino C++ object (Document, database etc) all use the same one handle. And at the end of the XPage load or partial refresh, everything good recycled.

So the only time you need to recycle is when looping through a collection. Then you need to recycle the variable. Plus, if you're creating DateTime or Name objects, you need to recycle those separately, because they're children of the Session, not of the ViewEntry/Document. Plus, if you're using getColumnValues() on a view that includes dates or times, regardless of whether you intend to use those columns, you still need to recycle the ColumnValues Vector. Searching for recycle and columnValues will  give various articles about how to do that.

Recycling in a repeat has potential for complications, because I don't know if it might recycle an underlying Doocument object for one column can cause problems for other columns accessing the same Document. If it happens, it's not going to be obvious and will be a PITA to identify. With the default 30 rows, you're only adding 30 handles, and that's unlikely to have an impact.

The challenges of when to recycle and when not to, particularly around DateTimes, was one of the main drivers behind creating OpenNTF Domino API. That means you never have to recycle anything - the API handles all that for you.

On performance, I've not investigated Bill's hypothesis on performance to a great degree. XPages Toolbox could tell some information. But bear in mind that the NotesXspViewEntry object is not the underlying ViewEntry. It's actually a Java wrapper class that allows it to be serialized, so for every column you add, it's got to get the value (and if it's a date / time convert it to the Java equivalent), then store it in the Java NotesXspViewEntry object, regardless of whether the current XPage uses it or not. .getDocument() won't store anything. Personally I've never encountered a noticeable performance hit of going to the Document and it's something I commonly do in applications.