The results you are seeing indicate that this is probably 4store executing the query slowly, and not anything to do with the Jena client. You could even take Jena out of the mix and test getting the results directly from the endpoint:
time curl --data-binary "@query1.txt" -H "Content-Type: application/sparql-query" "http://localhost:3030/ds/query"; >> /dev/null Unfortunately, databases are notorious for handling IN clauses poorly (even many SQL databases). If 4store supports all of SPARQL 1.1, then you can try changing the IN clause to a VALUES clause [1] and see if that helps. -Stephen [1] http://www.w3.org/TR/sparql11-query/#inline-data On Thu, Feb 28, 2013 at 10:30 AM, Burak Yönyül <[email protected]> wrote: > Hi, > > When I reduce FILTER block, the execution time of the query longs shorter, > but I receive less result than original query. So result set is reducing > too. > > I recorded each elapsed time round the while loop, and there is variability > at some looping times. The code that records times: > > int i = 0; > long before = System.currentTimeMillis(); > while (resultSet.hasNext()) { > i++; > resultSet.next(); > long after = System.currentTimeMillis(); > fileWriter.append("Time of " + i + ". result: " + (after - before)+" ms" > + "\n"); > before = System.currentTimeMillis(); > } > > The example output: > > Time of 1. result: 4 ms > Time of 2. result: 0 ms > Time of 3. result: 1 ms > ... > Time of 20. result: 14 ms > Time of 21. result: 0 ms > Time of 22. result: 1 ms > Time of 23. result: 1 ms > ... > Time of 27. result: 17 ms > Time of 28. result: 1 ms > ... > Time of 34. result: 10 ms > ... and so on. > > But when I execute LIMIT query, these times are all 0 or 1. > > I don't know that, why in FILTER query, there is time differences at > getting some results. Do you have any idea about that? > > Best, > Burak Yönyül > > > > 2013/2/28 Andy Seaborne <[email protected]> > >> On 28/02/13 12:44, Burak Yönyül wrote: >> >>> Hi Andy, >>> >>> Count query is executed in 20 miliseconds and it returns 71019 as count. >>> >> >> The basic pattern and count does not touch the values of the variables. >> So I'm inclined to think that the filter is the costly part. >> >> >> As I understand you, the query result is calculated when the http >>> request is sent in hasNext(). But, the results are not sent back to me >>> immediatly. The results are sent to me as long as I read them with >>> hasNext(). Am I right? >>> >> >> looks like the server has to go through a lot of the results of the >> pattern matching, testing against the FILTER, between >> >> If you want to explore what's going on, >> >> 1/ use a FILTER that is much shorter (10% of the length, say) and see what >> happens. This will not get you the right results but will yield >> information as to what 4Store might be doing. >> >> Printing the elapsed time at various points is more info. >> >> 2/ QueryExecutionFactory.**sparqlService is recreating the query - that >> might be a little slow. >> >> 3/ The elapsed time each time round the while loop - is it the same amount >> of time each time or is it variable? >> >> Andy >> >> >>> Burak >>> >> >>
