Hi Eliot,
I've never realised this.
My problem was that in benchmarks such as Richards I had issues with methods such as:
SMarkRichTaskState>>isTaskHoldingOrWaiting
^taskHolding or: [packetPending not and: [taskWaiting]]
which would get really slow due to counters. I believe this method should have zero or one counter, not 2. I implemented the cheap heuristic to remove counters on and:/or: for this purpose.
It would be better to have counters on the outermost if (in this case the or:) instead of the innermost (in this case the and:) for sure.
Now I don't think it matters that much because most counters trip on loops and most loops are following the #to:by:do: pattern where there is one condition then branch.
I would like to experiment in the future with other counting logic (more counters for more accurate profiling information), so I don't know if it matters to fix that now. I think the next step is either profiling more accurately, allocation optimisations or changes in the in-image compiler to decrease compilation time (DeltaBlue can get -30% execution time with high magic settings but unfortunately that means a huge slow down at first run due to high compilation time).