Complex SPARQL queries with OPTIONAL

Using the OPTIONAL keyword significantly slows down queries.
Like other simulated aggregate queries it may turn out to be faster to do the OPTIONALS as separate queries. However, I experienced some recent unexplained slowness, and it appears that's coming from the way I'm parsing the results in Sesame to get them back to PHP.

Earlier I experienced slowness with native PHP jason_decode(). Now there is something in the following code block I am doing which is slow. From the log files of the slowest query:

INFO - TIME OF EVAL QUERY: 0.34096098seconds of 0.34096098 total.
INFO - TIME OF Parsing results: 1.867237seconds of 2.2081978 total.

see also my post on the matter at http://www.openrdf.org/forum/mvnforum/viewthread?thread=1431

1.8 Seconds to parse the results! No subqueries. I must be choosing the wrong java datatypes! I there there are 800 or rows to the results, so that means building 800 hashtables. Not only are the hashtables built dynamically (I tried building a pool of them at construct time), but also, the parameters are retrieved dynamically. Maybe all this dynamic stuff makes java unhappy?


while (result.hasNext()) {
temp = new Hashtable(this.hashtableBufferCapacity);
bindingSet = result.next();

for (e = params.elements(); e.hasMoreElements();) {
param = (String) e.nextElement();
try{
if (bindingSet.hasBinding(param)){
value = bindingSet.getValue(param);
temp.put(param, value.toString() );
}
} catch (Exception ex) {
this.logger.error("basicGet() temp.put(param, value.toString() );"+ex.toString());
}
}
resultHolder.add(index,temp);
index++;
}