[ https://issues.apache.org/jira/browse/JENA-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346371#comment-17346371 ]
Andy Seaborne commented on JENA-2107: ------------------------------------- All the solvers need this fix. I've don RX4 and the TDB SolverRX's following the pattern from the PR. [~LorenzB] if you adjust he commit message on the PR, I'll do the other three. Would you be able to test the TDB (either one, ideally both)? I can't think of a test for the situation other than timing because the core of the RDF-star triple solver code is, by design, more general than assuming substitution has been done, which is why it didn't show except from a performance effect. > RDF Star performance issue with non-concrete node triples > --------------------------------------------------------- > > Key: JENA-2107 > URL: https://issues.apache.org/jira/browse/JENA-2107 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ > Affects Versions: Jena 3.17.0, Jena 4.0.0 > Reporter: Lorenz Bühmann > Priority: Critical > Fix For: Jena 4.1.0 > > > the following graph pattern is not evaluated efficiently (results in > full-scan per binding) because the second triple pattern doesn't take > advantage of the bindings generated by evaluation of the first one: > {code:java} > ?s <p> ?o . > << ?s <p> ?o >> <p2> ?v . > {code} > A possible fix would be to adapt the method {{rdfStarTripleSub()}} in class > > [SolverRX3.java|https://github.com/apache/jena/blob/2efff8a00b4ffa82751cf46c8a3fed84b6ff3090/jena-arq/src/main/java/org/apache/jena/sparql/engine/main/solver/SolverRX3.java#L63-L71] > by changing the beginning to > {code:java} > private static Iterator<Binding> rdfStarTripleSub(Binding input, Triple > xPattern, ExecutionContext execCxt) { > Triple tPattern = Substitute.substitute(xPattern, input); > {code} > We went from 75s for a very small dataset (50k triples) to near instant > response times. > If this fix is correct and doesn't break anything, it might be the same way > to fix for its quads counterpart in {{SolverRX4}} class. > > Note, for tdbquery, this seems to be evaluated at a different place? At > least, we couldn't find any performance improvement, it's still horribly slow. -- This message was sent by Atlassian Jira (v8.3.4#803005)