CL binary tree codes’ heap allocation profiling
Happy New Year to You

>I believe I've clearly explained everything I could with examples and profiling reports, and all I need is a profiler report to prove the fairness which I believe is clear and actionable.

Have you seen my messages regarding SBCL heap allocation profiling?
I am not sure if they went through.

Here are the heap allocation profiling results for a code using cons cells to store the binary tree and one for using struct to do the same clearly showing that cons as well as structs are allocated on heap for every and each instantiation.

1.cl with cons cells

```
CL-USER> (sb-aprof:aprof-run #'main :arguments 18)
stretch tree of depth 19	 check: 1048575
262144	 trees of depth 4	 check: 8126464
65536	 trees of depth 6	 check: 8323072
16384	 trees of depth 8	 check: 8372224
4096	 trees of depth 10	 check: 8384512
1024	 trees of depth 12	 check: 8387584
256	 trees of depth 14	 check: 8388352
64	 trees of depth 16	 check: 8388544
16	 trees of depth 18	 check: 8388592
long lived tree of depth 18	 check: 524287
553 (of 50000 max) profile entries consumed

       %        Bytes        Count    Function
 -------  -----------    ---------    --------
  99.5     1087722944                 BUILD-TREE
      50.5    549453824   34340864        CONS
      49.5    538269120   33641820        LIST

   0.5        5592320       349520    LOOP-DEPTHS - LIST
  00.0             32            2    BINARY-TREES-UPTO-SIZE - LIST
 =======  ===========
 100.0     1093315296

1093315296
CL-USER> ( + 34340864 33641820 349520 2) ;; is exactly equal to the sum of checks
68332206
```
5.cl with  struct

```
CL-USER> (sb-aprof:aprof-run #'main :arguments 18)
stretch tree of depth 19	 check: 1048575
262144	 trees of depth 4	 check: 8126464
65536	 trees of depth 6	 check: 8323072
16384	 trees of depth 8	 check: 8372224
4096	 trees of depth 10	 check: 8384512
1024	 trees of depth 12	 check: 8387584
256	 trees of depth 14	 check: 8388352
64	 trees of depth 16	 check: 8388544
16	 trees of depth 18	 check: 8388592
long lived tree of depth 18	 check: 524287
562 (of 50000 max) profile entries consumed

       %        Bytes        Count    Function
 -------  -----------    ---------    --------
  99.5     2175445888     67982684    BUILD-TREE - NODE
   0.5       11184640       349520    LOOP-DEPTHS - NODE
  00.0             64            2    BINARY-TREES-UPTO-SIZE - NODE
 =======  ===========
 100.0     2186630592

2186630592
CL-USER> (+ 67982684 349520 2) ;; is exactly equal to the sum of checks
68332206
```

And here is your example you demonstrated that OCaml is not doing what you expect according to 
callgrind profiling report.

Here is the heap allocation profiling report clearly showing that SBCL does it as you expect.

This is with the PR-ed 5.cl
```
(defun make-tree (n)
  (loop for i below n do (build-tree 1)))

CL-USER> (sb-aprof:aprof-run #'make-tree :arguments 10000)

8 (of 50000 max) profile entries consumed

       %        Bytes        Count    Function
 -------  -----------    ---------    --------
 100.0         960000        30000    BUILD-TREE - NODE
 =======  ===========
 100.0         960000

960000
CL-USER>
```

Therefore could you please accept my PR with the latest codes and rerun the benchmark including codes 1.cl 2.cl 5.cl and 6.cl since SBCL clearly allocates every nodes on the heap meeting requirements?

