Mario Rugiero
Mario Rugiero
Would it be reasonable to rebase with the new changeset?
It builds without issue in Mojave. I'd try Catalina, but I can't install it until my city's quarantine is over :(
I think it's worth documenting in the README that BE is only supported as a fallback and will suffer degraded performance for some operations. Just to avoid surprises and spurious...
I'm working on a PR to try and test on ppc64. I could add a line in that same PR about it.
@jacksonrnewhouse that's not the code that runs for little endian. Despite saying it's generic, because it technically is, for little endian this is what gets built: https://github.com/RoaringBitmap/roaring/blob/master/serialization_littleendian.go This performs better...
Regarding whether it is correct: we still need to test it, and we still prefer to update the build flags so LE use the LE-optimized path. We'll inevitably lag behind...
Just a suggestion: we should benchmark this in a parallel setting to make sure the synchronization doesn't hurt performance. Other than that I think it's a great idea.
Oh, sorry, I skimmed and thought the idea was using `sync.Pool` for containers rather than allowing resets.
I have individual bitmaps that are probably in the order of tens or hundreds of millions of values; I also use a huge number of them, but sizes are likely...
Was that benchmarked? For some reason I see no change on `EqualsSparse` and `EqualsClone` using that algorithm than with master.