-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix performance issues #241
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just some little things.
src/main/java/org/aksw/iguana/commons/time/DurationLiteral.java
Outdated
Show resolved
Hide resolved
src/main/java/org/aksw/iguana/cc/metrics/impl/AggregatedExecutionStatistics.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexander Bigerl <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as i can tell the spec of java.time.Duration matches xsd:dayTimeDuration and not xsd:duration.
(Except if the duration is >= 24 hours. Then java still outputs durations where it should output days. But the representation is still valid and should be accepted on parsing.)
During a test of the new iguana version, I noticed that there were some severe performance issues during the processing of the results, after the stresstest has finished. The biggest issue of it was the jena library and the
canonical
method inside itsXSDDuration
class, which didn't support nanoseconds as decimal digits for the durations.This PR aims to circumvent this issue by creating our own LiteralType class, which might not be the best solution.
I've also made the QuerySource cache its hashCode, which also caused some performance issues, as the hashCode is needed everytime the id of a Query from a QueryHandler is retrieved. Caching the QuerySource hashCode shouldn't be a problem though, as we don't expect the hashCode to change itself during the benchmark.