As it stands now, OrderedJoinSuccessorGenerator::parse_precond_into_join_program is doing a fair amount of unnecessary work:
First, it does a lot of copies (not moves) of Table objects, which will be expensive, e.g. here... but
Second, I'm not convinced that using a priority queue is efficient here... but
Third (this overrides the previous concerns), unless I'm mistaken, the ordering of the tables is done by arity, right? Arity is known at preprocessing time, so there's no point in using priority_queues, std::sorts(), or similar O(n*logn) (at best) operations... instead, we should precompile a map (an std::vector, implementation-wise) from positions in the return vector of Tables to precondition atoms. (A partial result table should be prepopulated with all data resulting from static info, as per #4). At runtime, we only go over this table in order, skipping static entries, and do the tuple selection.
If the above is correct, I'd rerun the experiments involving the OrderedJoinSuccessorGenerator.
As it stands now,
OrderedJoinSuccessorGenerator::parse_precond_into_join_programis doing a fair amount of unnecessary work:Tableobjects, which will be expensive, e.g. here... butIf the above is correct, I'd rerun the experiments involving the OrderedJoinSuccessorGenerator.