[PEAK] PEAK-Rules indexing performance
alberto at toscat.net
Fri Jan 9 07:03:17 EST 2009
We were struggling trying to optimize the bad performance (well,
horrible: about 4 seconds just to build the tree the first time a gf was
called with a different type signature) of a function heavily extended
with peak.rules. Finally, an "intuition driven" optimization  hit the
nail and performance improved *dramatically* (to < 0.1 s). This is the
Basically, some rules which were checking for set inclusion of an
argument in a set bound to "self" were changed so the inclusion check
was made against a list "inlined" into the same rule. Note that the
performance improvement is not at runtime, the performance here is fine,
but during the indexed tree building process when a gf is first called.
The profiler reveals many, many calls to "implies" and "overrides". More
details, wild guesses and profiler output are here:
The thing is that we'd like to further optimize if possible following
the same pattern or at least do it in a cleaner way. However, not
knowing the real reasons doesn't make us feel too comfortable... So,
please, can some light be shed over the reasons of this magical
 Since the only thing that came clear to us (well, sort of) from
cProfile was that time was being spent inside peak.rule's tree building.
Intuition and "lets try this" were our last last resort.
More information about the PEAK