Here is a link to a question that I just asked on stackoverflow http://stackoverflow.com/questions/28370227/when-do-i-need-to-recycle there are a couple of additional links in the answers that you should follow. 

Having said that the  getDocument is a pretty expensive call as it has to make a trip back to the server. Perhaps consider a different method of getting the data. a simple solution would be to put the email in the view that you are using to generate entry. Then the getColumnValue would retrieve it from memory rather than make another trip to the well.

I believe a pretty safe process on recycle is if it is a property do it unless the object is being returned or by recycling you destroy something that you need. for example if you recycle the DB object you lose access to any objects derived from it. So always recycle from the last object to the first object.

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.

To begin with I am not an expert on what happens in each of these cases but look at it from a logic perspective.

If in a repeat control the the returned row (I'll call it veData - viewEntry Data because the return looks and acts like a view Entry) I want to display 5 values. 

So in the first scenario I do not have the values in the view index so I need to execute veData.getDocument().getItemValueString("Field1") etc 5 times then the one row would require 5 trips back to the server - I don't know if the document gets cached locally but I doubt it. 

In the second scenario I have a view that contains all 5 fields so that the view index maintained by the server would contain all five field values. 

If I display veData it looks very much like an array of the field values. So once I have veData (an array) veData.geColumnValue("Field1") would simply parse the appropriate value out of the array defined by veData. 

So parsing the value from the veData array would seem to me to be a much cheaper action than 5 getDocuments plus then extract the value from the document because the view index has already done this and returned in one action the array veData. 

The question then becomes is there a measurable difference between the two methods on a one up basis and I would guess that the answer would be probably not. However, minimizing the number of hits on the server as a global premise would appear to be a worthwhile design consideration.

As I said to begin with I have not measured this nor am I an expert on all the inner workings of XPages, but this makes logical sense to me. If I am wrong on any part of my description above please let me know.