should we just get rid of AbstractColumnContainer now since it's basically just a wrapper around ISortedColumns?
It's still useful to factor the code between ColumnFamily and SuperColumn. If we remove it, we'll basically have to duplicate ACC into both CF and SC. But I'll be more than happy to remove it when/if we remove SCs
Doesn't Guava Functions.identity do the same as ACC.identity?
Totally, I guess I don't know Guava too well. I'll replace it.
I wonder if this is premature optimization or even counterproductive for the uncontended case. Did you do any testing around this?
To be honest, I did not test it. But the rational is that I would be surprised if checking an atomic ref get (even on each iteration) has any kind of visible impact (compared to adding a column to a snaptree), while I have no doubt that in the contended case with non trivially small batches not doing this will have a visible impact. That was more about trading a probably non-noticeable hit on non-contended to avoid any bad outliers.
I also though about doing the the reference check only every few iterations, but I figured that would likely don't change anything since again an atomic ref get should be really fast.
But obviously it doesn't cost much to check those assumptions and I'll do some testing.
I'll also note that we could easily change snaptree by a persistent sorted map. This could be faster than snaptree because there would be any internal synchronization (while snaptree has internal synchronization, that we mostly don't use, except for the fact that they allow a concurrently safe copy-on-write). I have a persistent store map implementation almost ready so I'll probably do that test at some point, but if we think snaptree is acceptable I suggest we go with that at first since it is absolutely unclear the persistent sorted map will be faster (it will generate more garbage for instance) and I'm sure how long it will take to do such a test.