Hey Marko,
Was this the ticket you were thinking?
https://issues.apache.org/jira/browse/TINKERPOP-1014

I think that could definitely make a difference.  I'll try to get the JMH
bit finished in the next few weeks so we have a
good base to work from.

I'll also put an investigation ticket in with some concrete examples for
the code-gen idea.

--Ted


On Tue, Feb 2, 2016 at 10:16 AM, Marko Rodriguez <okramma...@gmail.com>
wrote:

> Hello Ted,
>
> Dude, all of those items you list are so crucial to my efforts. If that
> infrastructure existed, I would have so much more confidence in each
> release.
>
> > * TinkerPop-965 - optimize strategy application
>
> This will be huge. I have a ticket around somewhere about getting rid of
> the TraversalRequirements-concept which should help to reduce clock-cycles.
>
> > * I'd like to familiarize myself with the OLAP side of things and
> hopefully
> > begin to help out a bit with those tickets.
>
> I can teach you this area of the codebase. There are lots of little nitty
> gritty areas here and there that could use work. Moreover, small
> optimizations lead to huge performance benefits because in OLAP, when you
> are processing billions of edges, if each edge is 100k less in size, well,
> thats (Xbillion * 100k)-less serialization/network traffic/etc. I think
> getting our Serializers micro-micro would be epic.
>
> > * Explore possibility of introducing code generation into certain steps
> to
> > cut down on traversal execution overhead.  Granted, the gains would need
> to
> > outweigh the cost of compilation of generated code.  Other folks have had
> > good success with this technique in certain scenarios.  See the code
> > generation portion of Spark's Tungsten project for one example [1].
>
> Hmmm… Can you provide an example? (ticket)
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
> > On Mon, Feb 1, 2016 at 5:01 PM, Marko Rodriguez <okramma...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Please bring this up on the respective ticket and we can discuss there.
> >> This way we don't steal this thread from 3.1.2 and 3.2.0 planning.
> >>
> >> Thanks,
> >> Marko.
> >>
> >> http://markorodriguez.com
> >>
> >> On Feb 1, 2016, at 2:30 PM, Marvin Froeder <velo...@gmail.com> wrote:
> >>
> >>> Any plans on making the return methods generic so we can specialize
> them?
> >>>
> >>> For instance, instead of
> >>> public interface Graph {
> >>> public Iterator<Vertex> vertices(final Object... vertexIds);
> >>> }
> >>> to have
> >>> public interface Graph<V extends Vertex> {
> >>> public Iterator<V> vertices(final Object... vertexIds);
> >>> }
> >>>
> >>>
> >>> That way, orientdb-gremlin can expose custom operations and even
> enforce
> >>> types for things like Element.id() and many other creative thinking =D
> >>>
> >>>
> >>> On Tue, Feb 2, 2016 at 3:52 AM, Marko Rodriguez <okramma...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I think 3.2.0 can include breaking changes if need be. However, I
> >> believe
> >>>> all the things that I want to do will be have @Deprecated backwards
> >>>> compatible solutions.
> >>>>
> >>>> Marko.
> >>>>
> >>>> http://markorodriguez.com
> >>>>
> >>>> On Feb 1, 2016, at 4:25 AM, Stephen Mallette <spmalle...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Is 3.2.0 going to be considered a "breaking" version in the sense
> that
> >> we
> >>>>> need to alter some APIs? or will it be possible to do 3.2.0 without
> >> that?
> >>>>> I'm in favor of a breaking version for 3.2.0 so that we can try to
> >> clean
> >>>> up
> >>>>> some old code especially if we have other changes driving that.
> >>>>>
> >>>>> On Sat, Jan 30, 2016 at 7:55 PM, Marko Rodriguez <
> okramma...@gmail.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello Pieter,
> >>>>>>
> >>>>>>> A tad selfish I know,
> >>>>>>> but https://issues.apache.org/jira/browse/TINKERPOP-968 is what I
> am
> >>>>>>> waiting for.
> >>>>>>
> >>>>>> The things I listed are what I care about and what I plan to work
> on.
> >> If
> >>>>>> you have things you care about, you can work on those. If you are
> >>>> unsure of
> >>>>>> a development strategy, perhaps you can get others excited about
> your
> >>>> idea
> >>>>>> with a [DISCUSS], work through pros/cons, get some buy in, etc. From
> >>>> there,
> >>>>>> develop the idea, test it, document it, and ultimately provide a PR
> to
> >>>> get
> >>>>>> it merged into a release line.
> >>>>>>
> >>>>>>      http://tinkerpop.apache.org/docs/3.1.1-SNAPSHOT/dev/developer/
> >>>>>>
> >>>>>> SIDENOTE: A few people emailed me personally saying comments to the
> >>>>>> effect: "Please deliver X, Y, Z feature." Note, if you want
> something
> >>>> done,
> >>>>>> do it. If you don't know how to do it, learn it. If you don't know
> how
> >>>> to
> >>>>>> learn it, ask and we can point you in the right direction. If you
> >> don't
> >>>>>> know how to ask -- I know you are lying cause you asked me to
> deliver
> >>>> X, Y,
> >>>>>> Z. Gotcha!
> >>>>>>
> >>>>>> Take care,
> >>>>>> Marko.
> >>>>>>
> >>>>>> http://markorodriguez.com
> >>>>>>
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>> Pieter
> >>>>>>>
> >>>>>>> On 30/01/2016 19:09, Marko Rodriguez wrote:
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> With TinkerPop 3.1.1 about to be put up for VOTE, we can start to
> >> turn
> >>>>>> our attentions towards 3.1.2 and 3.2.0.
> >>>>>>>>
> >>>>>>>> I was thinking it would be good to have a planning session to
> >> organize
> >>>>>> JIRA and discuss order of operations. However, JIRA planning
> sessions
> >>>> are a
> >>>>>> bit boring as they are too "nitty gritty," so perhaps we can use
> this
> >>>>>> thread to discuss what we (as individuals) would like to accomplish
> >> for
> >>>>>> 3.1.2 and 3.2.0 in general. This way, we have more summaries of
> >>>> everyone's
> >>>>>> desires and then the specifics can be shakin' out in JIRA. As such,
> >> here
> >>>>>> are my desires:
> >>>>>>>>
> >>>>>>>> TinkerPop 3.1.2
> >>>>>>>>   * Test a new shuffle optimization idea in SparkGraphComputer and
> >>>>>> if its efficient, use it.
> >>>>>>>>   * Benchmark GiraphGraphComputer at scale and optimize it where
> >>>>>> need be.
> >>>>>>>>
> >>>>>>>> TinkerPop 3.2.0
> >>>>>>>>   * Gremlin DSLs -- e.g.
> >>>>>>
> >>>>
> >>
> social.people().aged(36).who().know().person("daniel").who().worksFor().company("cisco")
> >>>>>>>>   * TraversalSource API redesign. g =
> >>>>>> graph.traversal().withComputer(…).withStrategy(…).withBulk(…). The
> >>>> current
> >>>>>> TraversalSourceBuilder model is horrible.
> >>>>>>>>   * OLTP/OLAP-mixed traversal -- e.g.
> >>>>>>
> >>>>
> >>
> OLAP[g.V().out()]OLTP[limit(10)]OLAP[out().values("name").order()]OLTP[sample(1)]
> >>>>>>>>   * GraphComputer API additions for intelligent data access --
> e.g.
> >>>>>> g.V().count() does not need to grab all the edges of the graph!
> >>>>>>>>   * Bulking beyond Long -- support BigInteger, Complex numbers,
> >>>>>> Doubles, etc.
> >>>>>>>>   * Redesign TraverserRequirements -- this is a rats nest that
> >>>>>> didn't really work out as planned and its inefficient. I think I can
> >>>> make
> >>>>>> this a lot more simple.
> >>>>>>>>   * ServerGraph/ServerStep/ServerStrategy -- like OLAP, but for
> >>>>>> GremlinServer -- e.g. [GraphStep, VertexStep, ServerStep]
> (collaborate
> >>>> with
> >>>>>> GremlinServer people on this).
> >>>>>>>>   * Scope.local & Scope.global rethinking -- count(local),
> >>>>>> dedup(local) … too many -- this is not manageable! What about
> >>>>>> g.V().groupCount().inside(order().limit(10)) instead of
> >>>>>> g.V().groupCount().order(local).limit(local,10).
> >>>>>>>>   * Clean up HadoopGraph configurations -- Why do we have
> >>>>>> gremlin.spark.graphInputRDD and gremlin.hadoop.graphInputFormat. We
> >>>> should
> >>>>>> just have one configuration: gremlin.hadoop.graphInputClass.
> >>>>>>>>   * Publish a tutorial on the Gremlin VM and compiling other
> >>>>>> languages to it. I would really like to have the gremlin-examples/
> >>>> package
> >>>>>> that Jason/Stephen were talking about.
> >>>>>>>>   * Optimize Gryo serialization and SparkGraphComputer's
> >>>>>> GryoSerializer.
> >>>>>>>>
> >>>>>>>> Those are the big ticket items that I would like to get handle for
> >> the
> >>>>>> next versions of TinkerPop.
> >>>>>>>>
> >>>>>>>> What are your thoughts on these and what are your thoughts on what
> >> you
> >>>>>> plan to accomplish in this next push?
> >>>>>>>>
> >>>>>>>> Take care,
> >>>>>>>> Marko.
> >>>>>>>>
> >>>>>>>> http://markorodriguez.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Reply via email to