Re: path query optimization

Hi, So the one thing I just copied into TINKERPOP-1372 was your ImmutablePath.currentLabels = currentLabels (vs. copying the set). You are right, step labels are immutable and thus, there is no need to copy the set over — a direct reference is sufficient. Regarding the

Re: path query optimization

The branch is TINKERPOP-1404 https://github.com/apache/tinkerpop/commit/c1556fe82c58527dc4425d23d1d69ce324e62cfa Cheers Pieter On 01/11/2016 15:23, Marko Rodriguez wrote: > What branch are you in? Perhaps give me URLs (to GitHub) to the files > touched? (if its not too many) > > Marko. > >

Re: path query optimization

What branch are you in? Perhaps give me URLs (to GitHub) to the files touched? (if its not too many) Marko. http://markorodriguez.com > On Nov 1, 2016, at 7:19 AM, pieter-gmail wrote: > > Hi, > > Yes I am but afraid I do not have time at present to concentrate on

Re: path query optimization

Hi, Yes I am but afraid I do not have time at present to concentrate on it. I just noticed your ImmutablePath ticket which will overlap with some of what I have done. I'd suggest to pull my branch and look at what I did there. It was very little, but dangerous code, which is why I was reluctant

Re: path query optimization

Hi Pieter, I’m still really interested in your work in this area. Are you still doing this? Marko. http://markorodriguez.com > On Aug 7, 2016, at 9:12 AM, Pieter Martin wrote: > > To avoid the collection logic alltogether. For most steps there is no need to > check

Re: path query optimization

Why not just check to see if the labels to be added already exist, if they do, don’t addLabels() and thus, don’t create a new collection. Marko. http://markorodriguez.com > On Aug 7, 2016, at 6:07 AM, Pieter Martin wrote: > > Here is what I have come up with so

Re: path query optimization

Here is what I have come up with so far. The idea is that `Traverser.split(r, step)` already copies the labels to the traverser so there is no need to call `Traverser.addLabels(labels)` again. I removed the `Traverser.addLabels(labels)` call from `AbstractStep`. For the traversers that do not

Re: path query optimization

Neat find Pieter. With regards to the update to ImmutablePath, I think that defensive copying of inbound collections is generally a good idea but if we can target specific areas where we can reap big gains from not creating new collections it may be worth it to relax that constraint, especially

Re: path query optimization

Hello, This is cool. Check out also ImmutablePath.extend(labels) as that is ultimately what Traverser.addLabels() calls. We have a lot of set copying and I don’t know if its needed (as you seem to be demonstrating). What I don’t like about your solution is the explicit reference to the

Re: path query optimization

Sorry forgot to add a rather important part. I changed ImmutablePath's constructor to private ImmutablePath(final ImmutablePathImpl previousPath, final Object currentObject, final Set currentLabels) { this.previousPath = previousPath; this.currentObject = currentObject;

RE: path query optimization

Hi, I have been optimizing Sqlg of late and eventually arrived at TinkerPop code. The gremlin in particular that I am interested is path queries. Here is the test that I am running in jmh. //@Setup Vertex a = graph.addVertex(T.label, "A", "name", "a1"); for (int i = 1;