> When running the all-inclusive version, have
> you tried displaying the
> "incremental" values for
> ProcessorTime as the upcard changes? If the
> extra time is spread out through all upcards
> proportionally, you probably won't learn
> anything, but if the extra time comes from
> just one or two upcards, it could help you
> zero in on the problem.

> Admittedly, it's a longshot! I'm just not
> believing that memory-allocation can be
> that expensive.

Ok, so the reason I had actually checked them all separately was for exactly the reason you stated, but I didn't think to check the individual times within the full run.

The result gives a partial explanation of how poor a programmer I am... When I did the run, all the upcards took about 50s. I realized right when I saw that, that when I run through the dealers hands, I use all of them and just multiply by zero for hands that aren't possible for a given upcard... When I run them separately, only the relevant dealer hands for the given upcard are determined. In a very early version of the program I had tried using only the relevant dealer hands vs multiplying by zero for the given upcards and the latter was faster for some reason. I'm guessing now with all the additions to the program the former will be, so I have to fix that now.

It's not the entire explanation though since the longest time for an individual upcard was with 2 and that was 25s - which is still 2x faster than the calculations for a 2 upcard when all are run together.

Great idea though and I'll let you know if it speeds things up adding a tag to ignore hands for given upcards. I'll also move the upcard loop to the outside since that cut some time off as well.

Thanks,
MGP