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++;
}