Karsten Bräckelmann wrote:
Would constructing it using a binary (or n-ary, with small upper bound
of n) tree speed the compilation up?
Err, Matt, just had a very brief look at the code and the resulting
metas, but -- how is that different? :)
The result is exactly the tree structure I mentioned, limiting the
number of children per node.
Blame that comment on lack of sleep - I read that as limiting the depth
of the tree and not being an n-ary tree.
Before
real 21m24.068s
After using 4 children
real 13m7.309s
After using 8 children
real 12m28.601s
Hmm, interesting, the results aren't linear. The 8-ary tree performs
much better than the flat meta. However, the 4-ary tree with even less
children per node (meta) doesn't improve this further.
I haven't had a chance to look at the SA compile code yet to see how it
works. I am going to run some more tests to see what impact the
different values have on the different parts of the sa-compile process.
I *think* that the actually compilation of the .c files was quicker
using 4 rather than 8 children.
I also want to look at the caching code - as with smaller 4-ary trees
the chance of keeping the same blocks would increase - assuming there is
some inteligence in the groupings.
Btw, there's a minor issue with the additional nodes not being non-
scoring sub-rules and thus scoring a default 1.0. Just to point it out,
I do realize this is a proof-of-concept hack. :)
Missed that - ta! Good job I am not running it in production!
matt
