On 16/01/13 22:48, Holger Knublauch wrote:
On Jan 17, 2013, at 12:52 AM, Andy Seaborne wrote:
On 16/01/13 01:02, Holger Knublauch wrote:
Hi Andy,
I ran a profiler through a typical scenario with our software and
discovered that 10% of the clocked time was spent in the initialization
of the xsd:dateTime literal needed by the afn:now() and NOW function.
Below is a snapshot from Yourkit profiler.
Unless this is a measurement error in the tool, I believe there would be
a low-hanging fruit to optimize performance if the value would be
computed on demand only. I do understand that you need to get the time
stamp for the duration of the whole query, but I believe it would be
much faster to simply get the current time millis as a long, and from
this derive the actual XSD literal only if someone really calls this
SPARQL method.
Thanks
Holger
Holger,
This isn't clear to me - I can not see the code context for the call to
NodeFactory.nodeAsDateTime.
what is the SPARQL query being executed?
Any QueryExecution. The relevant call tree starts in the class Context:
context.set(ARQConstants.sysCurrentTime, NodeFactory.nowAsDateTime()) ;
My suggestion is to use a different constant such as sysCurrentTimeMillis for a
simple long and compute the sysCurrentTime on demand only, on the first call of
the now function.
Holger,
What I need is a comparison - have you run with such a change? Your
suggestion looks sensible IF it addresses the root cause.
What is the profile with a dummy value for
context.set(ARQConstants.sysCurrentTime, NodeFactory.nowAsDateTime()) ;
because the report seems to show at least 889ms (0.9 seconds) per query.
My experience is that each query does not take almost 1 second overhead
in a warmed up JVM!
The profile shows 140ms in Integer.toString and 15ms in calcTimezone.
Have you run with such a change?
What is the profile with a dummy value for
context.set(ARQConstants.sysCurrentTime, NodeFactory.nowAsDateTime()) ;
otherwise isn't it better to look at Integer.toString because that is
used elsewhere?
(note - locale processing in Java is sometimes expensive and delayed and
it is needed for string conversions)
And which version of Jena/ARQ is this?
Andy
HTH
Holger
Is this the first query to run in the JVM?
Are you running a single query in a fresh JVM?
Is there a nested select?
Andy
