[jira] [Commented] (TINKERPOP-1676) Improve GraphSON 2.0 Performance

2017-05-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025278#comment-16025278
 ] 

ASF GitHub Bot commented on TINKERPOP-1676:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/614

TINKERPOP-1676 (master) GraphSON Performance

https://issues.apache.org/jira/browse/TINKERPOP-1676

Had to do a separate PR for this as we've made changes in testing IO on 
master - see #613 for more details on what this PR is about.

Running the full build now - will edit this PR when it's done successfully.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1676-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/614.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #614


commit 46e6e9767b6818f33b56366ee15d80cec5a908e0
Author: Stephen Mallette 
Date:   2017-05-23T20:03:17Z

TINKERPOP-1676 Got rid of stream() usage

Can't believe we still had stream() in here. Will it ever all be gone from 
these performance sensitive places?! Anyway, removed that and deprecated a 
constructor on DetachedEdge that was using Pair for no really good reason. No 
need to create extra Pair objects for that. They just sorta get thrown away 
after usage.

commit 251f5b7e34e8ebd9a8bc36802e633be8c91eeb5e
Author: Stephen Mallette 
Date:   2017-05-23T20:57:12Z

TINKERPOP-1676 Improved speed and memory usage of GraphSON

This change is specific to TinkerGraph and the serialization of 
vertices/edges/properties. Removed a "middle layer" of JSON to Object 
serialization which was coercing JSON to Map first and then converting that to 
the graph elements. Also made deserializers cacheable.

commit 02b007366b434918fe1181f99d80689c1c03684b
Author: Stephen Mallette 
Date:   2017-05-24T00:13:46Z

TINKERPOP-1676 Performance enhancement to graphson serialization

Focuses on speeding up serialization of graph elements. Prevent use of 
generic maps and stream graphson data directly into "detached" elements. Not 
using intermediate maps cut down on memory usage and a bunch of jackson 
reflection calls (still not sure what they were for and why they were not made 
to be more efficient). It did mean some ugly changes to "detached" stuff. Will 
need to maybe refactor some more, but the basic premise seems to be proven.

commit e5d2d2bc000654fd026521219cf30bac265139a3
Author: Stephen Mallette 
Date:   2017-05-24T17:38:16Z

TINKERPOP-1676 Removed properties from graphson serialization of Path

Path should not have properties on elements (if they are present). That is 
inconsistent with gryo and was unintentially allowed.

commit 049c979720a84ea9744725fda5f8d2b371ab1751
Author: Stephen Mallette 
Date:   2017-05-25T17:29:45Z

TINKERPOP-1676 More optimizations to GraphSON serializers

Added some tests where there were previously gaps.

commit f32d725a080d39ef7bf93c68d8080939f622cb37
Author: Stephen Mallette 
Date:   2017-05-25T18:03:29Z

TINKERPOP-1676 Cleaned up serialization with detached

The DetachedUtil was just there to test out if the performance changes 
would help and it did it's job nicely, but it was kinda ugly and hung some 
methods out there in weird way. Cleaned that up with some builder pattern on 
the detached classes themselves.

commit bb7ff8290962e30dd4d78c4bd904eef31a3f2478
Author: Stephen Mallette 
Date:   2017-05-25T19:25:32Z

Merge branch 'TINKERPOP-1676' into TINKERPOP-1676-master

Conflicts:
docs/src/dev/io/graphson.asciidoc




> Improve GraphSON 2.0 Performance
> 
>
> Key: TINKERPOP-1676
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1676
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
>
> Not sure what will happen here. Just wanted an issue where I could experiment 
> a bit with and gather feedback from others for collaboration in case others 
> had ideas. Right now, GraphSON reads are considerably slower than Gryo and 
> writes appear to be faster, so the focus will be on how to get reads more in 
> line with what Gryo can do. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #614: TINKERPOP-1676 (master) GraphSON Performance

2017-05-25 Thread spmallette 
GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/614

TINKERPOP-1676 (master) GraphSON Performance

https://issues.apache.org/jira/browse/TINKERPOP-1676

Had to do a separate PR for this as we've made changes in testing IO on 
master - see #613 for more details on what this PR is about.

Running the full build now - will edit this PR when it's done successfully.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1676-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/614.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #614


commit 46e6e9767b6818f33b56366ee15d80cec5a908e0
Author: Stephen Mallette 
Date:   2017-05-23T20:03:17Z

TINKERPOP-1676 Got rid of stream() usage

Can't believe we still had stream() in here. Will it ever all be gone from 
these performance sensitive places?! Anyway, removed that and deprecated a 
constructor on DetachedEdge that was using Pair for no really good reason. No 
need to create extra Pair objects for that. They just sorta get thrown away 
after usage.

commit 251f5b7e34e8ebd9a8bc36802e633be8c91eeb5e
Author: Stephen Mallette 
Date:   2017-05-23T20:57:12Z

TINKERPOP-1676 Improved speed and memory usage of GraphSON

This change is specific to TinkerGraph and the serialization of 
vertices/edges/properties. Removed a "middle layer" of JSON to Object 
serialization which was coercing JSON to Map first and then converting that to 
the graph elements. Also made deserializers cacheable.

commit 02b007366b434918fe1181f99d80689c1c03684b
Author: Stephen Mallette 
Date:   2017-05-24T00:13:46Z

TINKERPOP-1676 Performance enhancement to graphson serialization

Focuses on speeding up serialization of graph elements. Prevent use of 
generic maps and stream graphson data directly into "detached" elements. Not 
using intermediate maps cut down on memory usage and a bunch of jackson 
reflection calls (still not sure what they were for and why they were not made 
to be more efficient). It did mean some ugly changes to "detached" stuff. Will 
need to maybe refactor some more, but the basic premise seems to be proven.

commit e5d2d2bc000654fd026521219cf30bac265139a3
Author: Stephen Mallette 
Date:   2017-05-24T17:38:16Z

TINKERPOP-1676 Removed properties from graphson serialization of Path

Path should not have properties on elements (if they are present). That is 
inconsistent with gryo and was unintentially allowed.

commit 049c979720a84ea9744725fda5f8d2b371ab1751
Author: Stephen Mallette 
Date:   2017-05-25T17:29:45Z

TINKERPOP-1676 More optimizations to GraphSON serializers

Added some tests where there were previously gaps.

commit f32d725a080d39ef7bf93c68d8080939f622cb37
Author: Stephen Mallette 
Date:   2017-05-25T18:03:29Z

TINKERPOP-1676 Cleaned up serialization with detached

The DetachedUtil was just there to test out if the performance changes 
would help and it did it's job nicely, but it was kinda ugly and hung some 
methods out there in weird way. Cleaned that up with some builder pattern on 
the detached classes themselves.

commit bb7ff8290962e30dd4d78c4bd904eef31a3f2478
Author: Stephen Mallette 
Date:   2017-05-25T19:25:32Z

Merge branch 'TINKERPOP-1676' into TINKERPOP-1676-master

Conflicts:
docs/src/dev/io/graphson.asciidoc




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #613: TINKERPOP-1676 (tp32) GraphSON Performance

2017-05-25 Thread spmallette 
GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/613

TINKERPOP-1676 (tp32) GraphSON Performance

https://issues.apache.org/jira/browse/TINKERPOP-1676

Made some pretty good improvements to performance. I was mostly focused on 
the serialization of complete graph elements so using TinkerGraph as the basis 
for benchmark seemed like a good way to do that.  I subgraphed a portion of the 
Grateful Dead graph:

```text
gremlin> subgraph = 
g.E().hasLabel('followedBy').subgraph('subGraph').cap('subGraph').next()
==>tinkergraph[vertices:338 edges:7047]
```

I wanted a comparison with Gryo so I got that first:

```text
gremlin> gryo = graph.io(IoCore.gryo()).mapper().create().createMapper()
==>org.apache.tinkerpop.shaded.kryo.Kryo@5edf2821
gremlin> clock { 
..1>   def s = new java.io.ByteArrayOutputStream()
..2>   def output = new org.apache.tinkerpop.shaded.kryo.io.Output(s)
..3>   gryo.writeObject(output, subgraph) 
..4>   output.flush()
..5>   def input = new 
org.apache.tinkerpop.shaded.kryo.io.Input(s.toByteArray())
..6>   gryo.readObject(input, TinkerGraph.class) 
..7> }
==>55.9679167999
```

then compared head of tp32:

```text
gremlin> graphson = 
GraphSONMapper.build().version(GraphSONVersion.V2_0).addCustomModule(GraphSONXModuleV2d0.build().create(false)).addRegistry(TinkerIoRegistryV2d0.instance()).create().createMapper()
==>org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper@185f7840
gremlin> clock { 
..1>   def s = new java.io.ByteArrayOutputStream()
..2>   graphson.writeValue(s, subgraph)
..3>   graphson.readValue(new 
java.io.ByteArrayInputStream(s.toByteArray()), TinkerGraph.class)
..4> }
==>723.170254179
```

pretty bad - now GraphSON with changes from this branch:

```text
gremlin> graphson = 
GraphSONMapper.build().version(GraphSONVersion.V2_0).addCustomModule(GraphSONXModuleV2d0.build().create(false)).addRegistry(TinkerIoRegistryV2d0.instance()).create().createMapper()
==>org.apache.tinkerpop.shaded.jackson.databind.ObjectMapper@563a89b5
gremlin> clock { 
..1>   def s = new java.io.ByteArrayOutputStream()
..2>   graphson.writeValue(s, subgraph)
..3>   graphson.readValue(new 
java.io.ByteArrayInputStream(s.toByteArray()), TinkerGraph.class)
..4> }
==>67.0219281
```

Not too far behind gryo now!

Running full integration tests now and will update this PR when it's done 
successfully. 




You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1676

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/613.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #613


commit 46e6e9767b6818f33b56366ee15d80cec5a908e0
Author: Stephen Mallette 
Date:   2017-05-23T20:03:17Z

TINKERPOP-1676 Got rid of stream() usage

Can't believe we still had stream() in here. Will it ever all be gone from 
these performance sensitive places?! Anyway, removed that and deprecated a 
constructor on DetachedEdge that was using Pair for no really good reason. No 
need to create extra Pair objects for that. They just sorta get thrown away 
after usage.

commit 251f5b7e34e8ebd9a8bc36802e633be8c91eeb5e
Author: Stephen Mallette 
Date:   2017-05-23T20:57:12Z

TINKERPOP-1676 Improved speed and memory usage of GraphSON

This change is specific to TinkerGraph and the serialization of 
vertices/edges/properties. Removed a "middle layer" of JSON to Object 
serialization which was coercing JSON to Map first and then converting that to 
the graph elements. Also made deserializers cacheable.

commit 02b007366b434918fe1181f99d80689c1c03684b
Author: Stephen Mallette 
Date:   2017-05-24T00:13:46Z

TINKERPOP-1676 Performance enhancement to graphson serialization

Focuses on speeding up serialization of graph elements. Prevent use of 
generic maps and stream graphson data directly into "detached" elements. Not 
using intermediate maps cut down on memory usage and a bunch of jackson 
reflection calls (still not sure what they were for and why they were not made 
to be more efficient). It did mean some ugly changes to "detached" stuff. Will 
need to maybe refactor some more, but the basic premise seems to be proven.

commit e5d2d2bc000654fd026521219cf30bac265139a3
Author: Stephen Mallette 
Date:   2017-05-24T17:38:16Z

TINKERPOP-1676 Removed properties from graphson serialization of Path

Path should not have properties on elements (if they

[jira] [Updated] (TINKERPOP-1676) Improve GraphSON 2.0 Performance

2017-05-25 Thread stephen mallette (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1676:

Summary: Improve GraphSON 2.0 Performance  (was: Improve GraphSON 
Performance)

> Improve GraphSON 2.0 Performance
> 
>
> Key: TINKERPOP-1676
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1676
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.4
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
>
> Not sure what will happen here. Just wanted an issue where I could experiment 
> a bit with and gather feedback from others for collaboration in case others 
> had ideas. Right now, GraphSON reads are considerably slower than Gryo and 
> writes appear to be faster, so the focus will be on how to get reads more in 
> line with what Gryo can do. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1677) Bump Groovy to 2.4.11

2017-05-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025054#comment-16025054
 ] 

ASF GitHub Bot commented on TINKERPOP-1677:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/612
  
VOTE +1


> Bump Groovy to 2.4.11
> -
>
> Key: TINKERPOP-1677
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1677
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.4
>Reporter: Andrea Cosentino
> Fix For: 3.3.0, 3.2.5
>
>
> Just a minor release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #612: TINKERPOP-1677 Bump Groovy to 2.4.11

2017-05-25 Thread spmallette 
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/612
  
VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Article] Open Problems in the Universal Graph Theory

2017-05-25 Thread Marko Rodriguez 
Hi,

For those that want the “short version” or at least a “prep” to the purpose of 
the article. Here goes:

1. I open the with a propositional axiom that states that everything is 
a graph composed of vertices and edges.
2. From there I discuss the deductive entailments of that axiom on 
time, consciousness, and the “laws of physics.”
3. Those entities must have a structural encoding if everything is just 
"dots and lines.”
4. A structural encoding implies malleability and thus, it is possible 
to, in a computationally reflective manner, alter the process of time, 
consciousness, and the laws of physics.

QED,
Marko.

http://markorodriguez.com



> On May 25, 2017, at 9:14 AM, Marko Rodriguez  wrote:
> 
> Hello,
> 
> For next month’s GraphDay conference, I decided to talk about 3 areas in 
> graph theory/computing where my mind goes “blank.” These areas of thought are 
> where I have no clever solutions and hopefully it will spur a new generation 
> of graph thinkers to see further into the wonderful world of graphs.
> 
>   https://twitter.com/twarko/status/867746505049858048 
> 
> 
> Enjoy!,
> Marko.
> 
> http://markorodriguez.com 
> 
> 
>

[Article] Open Problems in the Universal Graph Theory

2017-05-25 Thread Marko Rodriguez 
Hello,

For next month’s GraphDay conference, I decided to talk about 3 areas in graph 
theory/computing where my mind goes “blank.” These areas of thought are where I 
have no clever solutions and hopefully it will spur a new generation of graph 
thinkers to see further into the wonderful world of graphs.

https://twitter.com/twarko/status/867746505049858048 


Enjoy!,
Marko.

http://markorodriguez.com

[jira] [Closed] (TINKERPOP-1675) RemoteStep#processNextStart() throws CompletionException instead of underlying exception

2017-05-25 Thread stephen mallette (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1675.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.2.5

> RemoteStep#processNextStart() throws CompletionException instead of 
> underlying exception
> 
>
> Key: TINKERPOP-1675
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1675
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Andy Tolbert
>Assignee: stephen mallette
> Fix For: 3.2.5
>
>
> There is a slight behavior change in TinkerPop 3.2.4 as it pertains to an 
> exception thrown when processing a traversal on a remote traversal source.
> In 3.2.3, if an unchecked exception is thrown, it is propagated directly to 
> the user.
> However, in 3.2.4, since RemoteStep#processNextStart() now calls 
> RemoteStep#promise() and joins on the returning futures result, if the future 
> fails a {{CompletionException}} is thrown wrapping the cause, instead of the 
> cause itself.
> For consistency, if that exception is an unchecked exception, it should be 
> thrown directly, otherwise it should be wrapped in an 
> {{IllegalStateException}} as it did before.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1675) RemoteStep#processNextStart() throws CompletionException instead of underlying exception

2017-05-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024754#comment-16024754
 ] 

ASF GitHub Bot commented on TINKERPOP-1675:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/609


> RemoteStep#processNextStart() throws CompletionException instead of 
> underlying exception
> 
>
> Key: TINKERPOP-1675
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1675
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Andy Tolbert
>
> There is a slight behavior change in TinkerPop 3.2.4 as it pertains to an 
> exception thrown when processing a traversal on a remote traversal source.
> In 3.2.3, if an unchecked exception is thrown, it is propagated directly to 
> the user.
> However, in 3.2.4, since RemoteStep#processNextStart() now calls 
> RemoteStep#promise() and joins on the returning futures result, if the future 
> fails a {{CompletionException}} is thrown wrapping the cause, instead of the 
> cause itself.
> For consistency, if that exception is an unchecked exception, it should be 
> thrown directly, otherwise it should be wrapped in an 
> {{IllegalStateException}} as it did before.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #609: TINKERPOP-1675 Throw underlying unchecked excep...

2017-05-25 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/609


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1669) EdgeVertexStep should be designed for extension

2017-05-25 Thread Bryn Cooke (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024532#comment-16024532
 ] 

Bryn Cooke commented on TINKERPOP-1669:
---

I have recently embarked upon a review of how we are integrating our graph 
implementation with Tinkerpop. Previously we had significant traversal 
rewriting going on, and would add and remove steps. However, it turns out that 
maintaining correctness when doing this is actually quite hard. Instead I am 
taking a much less invasive approach by simply replacing the element steps with 
internal classes while leaving the rest of the traversal alone.
This has a couple of advantages:
1. It's much easier to reason about.
2. We can optimise for much more complicated traversals, correctly handling AND 
and OR. If our backend can't mimic the expressiveness of TP we can do as much 
as possible and allow the TP traversal to handle the rest.



> EdgeVertexStep should be designed for extension
> ---
>
> Key: TINKERPOP-1669
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1669
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, structure
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> GraphStep, VertexStep and PropertiesStep are all not final, so I was 
> surprised to find that I couldn't extend EdgeVertexStep. In the end I had to 
> duplicate the entire class
> If there are concerns about simply making this class non-final then it could 
> be designed for extension by making most of the methods final (except 
> toString), but the leaving the class non-final.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1637) Expose metrics attributes in string output

2017-05-25 Thread Bryn Cooke (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024495#comment-16024495
 ] 

Bryn Cooke commented on TINKERPOP-1637:
---

Something like:
{noformat}
gremlin> g = 
EmptyGraph.instance().traversal().withRemote('conf/remote-graph.properties')
==>graphtraversalsource[emptygraph[empty], standard]
gremlin> g.V().out().out().profile().next().toString()
==>Traversal Metrics
Step   Count  
Traversers   Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 1
   1   0.05121.09
   key1=value1
   key2=value2
VertexStep(OUT,vertex)  
   0.06827.90
   key1=value1
   key3=value3
NoOpBarrierStep(2500)   
   0.03614.64
   key1=value1
VertexStep(OUT,vertex)  
   0.03815.63
   key1=value1
   key3=value3
NoOpBarrierStep(2500)   
   0.05120.74
>TOTAL -
   -   0.246-
{noformat}

> Expose metrics attributes in string output
> --
>
> Key: TINKERPOP-1637
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1637
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently the profile step won't expose metrics attributes in the string 
> output. This means that useful information provided by graph implementations 
> is never output.
> It would be great if the attributes could be output indented under each 
> metric.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1637) Expose metrics attributes in string output

2017-05-25 Thread Bryn Cooke (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024494#comment-16024494
 ] 

Bryn Cooke commented on TINKERPOP-1637:
---

It is the contents of ImmutableMetrics#annotations. This map is presumably 
there for TP implementors to add extra implementation specific information, but 
as it's not output to the console it's painful for the users to get at.

> Expose metrics attributes in string output
> --
>
> Key: TINKERPOP-1637
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1637
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Bryn Cooke
>
> Currently the profile step won't expose metrics attributes in the string 
> output. This means that useful information provided by graph implementations 
> is never output.
> It would be great if the attributes could be output indented under each 
> metric.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)