I’m supportive and not aware of any blockers. One consideration on approach: David has done some experimentation with loop-based optimization. His work demonstrates a lot of promise, but with a caveat that as the loop approaches optimality the complexity of the patch can increase at a rate that outpaces its value. I’d be curious how this approach handles that tradeoff.
And one for the project: if use of the software creates any obligation for Apache Cassandra such as referenceability in the vendor’s press materials etc., that would need to be discussed and voted on by the PMC prior to creating any such obligation. — Mobile > On Jul 8, 2026, at 5:59 AM, Alex Petrov <[email protected]> wrote: > > > Hey folks, > > A friend of mine is building Perfloop [1]; the way they describe it, "closed > loop performance engineering". They already have several upstream OSS merges, > including two in parquet-go [2] and one in RoaringBitmap/roaring [3], all > benchmark-verified. > > I was curious if they can find anything in Cassandra, so asked them to try it > against our repo, and they've found a bunch of performance improvements, many > of which seem to be quite easy to review and verify. All of them come with a > finding, benchmark, a patch, and verification of an improvement, which is > pretty useful for a reviewer. > > I've looked over the issues, and will be reviewing and committing some of > them. Is there anything that prevents us from committing the patches that > were fully LLM-authored, assuming contents are solid? > > --Alex > > [1] https://perfloop.ai/ > [2] https://github.com/parquet-go/parquet-go/pull/550 > [3] https://github.com/RoaringBitmap/roaring/pull/532
