On 05/16/2012 11:43 AM, wren ng thornton wrote:
Also, have you compared your transitive reduction to just outputting the whole graph and then using `tred`? The latter approach has the distinct downside of needing to serialize the whole graph; but it could still be a win unless you intend to implement similar algorithms yourself. The smart algorithms do *much* better than brute force.
I've done some profiling and found that the executable is spending about half of its time executing my brute force graph algorithm. So doing something smarter here (like using "tred") seems like a good idea. The bad news is that without running my inefficient algorithm the executable still doesn't scale well. Maybe there is a better way to let the darcs library compute the patch dependencies.
And of course it'd be nice to be able to pass arguments to the program in order to filter and otherwise manipulate the resulting graph. A lot of that can be done by special programs which only know about the Dot language (e.g., tred), so you should only focus on things which aren't captured by the Dot language or are otherwise only knowable by querying Darcs.
Sounds reasonable. Command line options would be nice.