Please see my comments below.
>1. Automatic generation of BDD trace files. This is controlled by a
>compile-time switch, so if you don't define the switch, nothing is changed.
>Basically it involves adding a line at the start of every BDD API function,
>and changing "return" instructions to a "RETURN" macro. It touches almost
>every function in BuDDy, but I think it is pretty minor because it will be
>disabled by default.
That's a nice feature, but one can easily use gprof to analyze the trace
of a program.
It gives you a nice dynamic call graph. However, it does not trace
parameters and return values to/from functions.
You can add such mechanism to every program, but - isn't that what
debuggers are for ?
My opinion is that it is a "nice to have" debugging feature.
We can wait for other developers' comments.
>2. Preallocation of memory for node table. Without this patch, BuDDy runs
>out of memory very quickly, especially on Windows machines (at as low as 12M
>nodes). This patch reduces the fragmentation by preallocating a large
>memory area and performing initialization on demand. This is about a 10
Sounds like a good performance improvement to me.
I think it must be tested with various node table's initial size and
size increasing parameters.
My opinion is to go ahead with this and commit to CVS.
>that I can check them in under a new CVS branch until people are convinced
>of the stability.
I think that we should minimize branching to minimum. Having one
code-stream will give all of us the option to check all the features
However, you should be confident in the code you commit.
As I said earlier - the person who commit to CVS should be careful and
commit near-to-stable code, and the person who update from CVS should
regard CVS with suspicion about its stability. I think that this
approach will be the most helpful to keep buddy bug rate to minimum,
while still keeping innovation.
I would appreciate your comments, John.