Michael Pollmeier recently authored a blog post that described how their fork of TinkerGraph memory usage could be reduced by 70% assuming usage of a strict schema:
https://blog.shiftleft.io/open-sourcing-our-specialized-tinkergraph-with-70-memory-reduction-and-strict-schema-validation-fa5cfb3dd82d The question at this point, is whether or not similar enhancements should be made to TinkerPop's TinkerGraph. I've had a few minutes to get to understand the changes that make the memory improvement possible - here's my thoughts: 1. This was a clever way to extend TinkerGraph. 2. The schema is implemented by way of concrete graph element classes shown here: https://github.com/ShiftLeftSecurity/tinkergraph-gremlin/tree/master/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/specialized/gratefuldead 3. Given that approach, you give up some flexibility in favor of improved memory usage 4. This approach started to feel sufficiently different to me to warrant this improvement as being more than just a "performance enhancement" and more like a fundamental change to what TinkerGraph is about. 5. Of course, Michael had said on the user mailing list that the strict schema was optional - though you needed to use it to get the improved memory usage. 6. So....I think the questions forming in my mind are: (a) do we want a major new feature (schema support) on TinkerGraph? (b) if so, is the schema support implemented in the manner in which we would want it (i.e. concrete classes)? (c) is this new feature changing TinkerGraph's mission in TinkerPop? (d) if so, should it simply remain as a fork (presumably under a different name to avoid confusion) so that it is not bound by what TinkerGraph is meant to be and can develop more freely?. I'll leave it at that for now and see what other people think. Irrespective of how this ends, I'd quickly offer another round of thanks to Michael and his colleagues for coming up with a neat feature and performance enhancement that could be useful to the TinkerPop community.
