The Quest for Performance: tuple and match representation, memories

[bergmanngabor]

Experiment with:

• left/right/dual inheritance of tuples
• tuple ordering to enhance indexer sharing
• smart adaptation of these strategies
• tuple-backed match, hash code storage, etc.

[bergmanngabor]

From earlier notes:

• PatternMemory.toArray <- called by DualInputNode.retrieveOpposites and MatchFetcher.run... is size() dominant?
• retrieveOpposites -> deduplicate!

[bergmanngabor]

• more clever Receiver interface (e.g. unify with indexer? two-phase update with message creation?)
• more lightweight message passing (old experimental patch still available in Viatra code, see also code snippet below)

    public void sendUpdate(Receiver receiver, Direction direction, Tuple updateElement) 
    {
        if (org.eclipse.viatra2.gtasm.patternmatcher.incremental.rete.util.Options.synchronous) receiver.update(direction, updateElement);
        else {
            messageQueue.addLast(new UpdateMessage(receiver, direction, updateElement));
        }
    }

[bergmanngabor]

• Collection implementations:
  • Use MultiMap (from Guava or other libraries) to back MaskedTupleMemories in indexers
  • Use MultiSet (from Guava or other libraries) to back TupleMemories in production nodes
  • Use Set (from JRE, Guava or other libraries) to back TupleMemories in input UniquenessEnforcers
  • experiment with collection frameworks

[bergmanngabor]

Migrated to https://bugs.eclipse.org/bugs/show_bug.cgi?id=398765