Performance improvement patches from Perfloop

[Alex Petrov <al...@coffeenco.de>]

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

Re: Performance improvement patches from Perfloop

[Ekaterina Dimitrova <ed...@apache.org>]

Thanks Aleks, I think this is the ASF legal guidance at the moment - https://apache.org/legal/generative-tooling.html

On 2026/07/08 21:25:03 Francisco Guerrero wrote:
> No concerns from my end as long as the patches are
> small and self-contained. I can also volunteer to review
> some of the patches.
> 
> Best,
> - Francisco
> 
> On 2026/07/08 21:22:43 Patrick McFadin wrote:
> > And sidebar. I've been looking at RoaringBitmap, and besides a really
> > awesome name, pretty impressive stuff there.
> > 
> > On Wed, Jul 8, 2026 at 1:13 PM Alex Petrov <al...@coffeenco.de> wrote:
> > 
> > > Good point!
> > >
> > > From what I understand even though there’s “loop” in the name it has
> > > preceded a current wave of agentic looping. In other words, they use same
> > > methodology one would when searching for performance improvements:
> > > measurement profiling hypothesis etc., and then go through multiple
> > > evaluation stages.
> > >
> > > Contributions are not coming with any conditions: agent just posts a
> > > patch, and all associated documentation and hypothesis is freely available.
> > >
> > > From what I understand, mentioning that X has found an issue in an open
> > > source project is ok (similar to how a researcher can claim a found issue);
> > > that of course can’t imply that Cassandra logo can be used in vendor
> > > materials. Thank you for pointing that out.
> > >
> > > On Wed, Jul 8, 2026, at 9:55 PM, C. Scott Andreas wrote:
> > >
> > > 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 <al...@coffeenco.de> 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
> > >
> > >
> > >
> > 
> 

Re: Performance improvement patches from Perfloop

[Francisco Guerrero <fr...@apache.org>]

No concerns from my end as long as the patches are
small and self-contained. I can also volunteer to review
some of the patches.

Best,
- Francisco

On 2026/07/08 21:22:43 Patrick McFadin wrote:
> And sidebar. I've been looking at RoaringBitmap, and besides a really
> awesome name, pretty impressive stuff there.
> 
> On Wed, Jul 8, 2026 at 1:13 PM Alex Petrov <al...@coffeenco.de> wrote:
> 
> > Good point!
> >
> > From what I understand even though there’s “loop” in the name it has
> > preceded a current wave of agentic looping. In other words, they use same
> > methodology one would when searching for performance improvements:
> > measurement profiling hypothesis etc., and then go through multiple
> > evaluation stages.
> >
> > Contributions are not coming with any conditions: agent just posts a
> > patch, and all associated documentation and hypothesis is freely available.
> >
> > From what I understand, mentioning that X has found an issue in an open
> > source project is ok (similar to how a researcher can claim a found issue);
> > that of course can’t imply that Cassandra logo can be used in vendor
> > materials. Thank you for pointing that out.
> >
> > On Wed, Jul 8, 2026, at 9:55 PM, C. Scott Andreas wrote:
> >
> > 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 <al...@coffeenco.de> 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
> >
> >
> >
> 

Re: Performance improvement patches from Perfloop

[Patrick McFadin <pm...@gmail.com>]

And sidebar. I've been looking at RoaringBitmap, and besides a really
awesome name, pretty impressive stuff there.

On Wed, Jul 8, 2026 at 1:13 PM Alex Petrov <al...@coffeenco.de> wrote:

> Good point!
>
> From what I understand even though there’s “loop” in the name it has
> preceded a current wave of agentic looping. In other words, they use same
> methodology one would when searching for performance improvements:
> measurement profiling hypothesis etc., and then go through multiple
> evaluation stages.
>
> Contributions are not coming with any conditions: agent just posts a
> patch, and all associated documentation and hypothesis is freely available.
>
> From what I understand, mentioning that X has found an issue in an open
> source project is ok (similar to how a researcher can claim a found issue);
> that of course can’t imply that Cassandra logo can be used in vendor
> materials. Thank you for pointing that out.
>
> On Wed, Jul 8, 2026, at 9:55 PM, C. Scott Andreas wrote:
>
> 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 <al...@coffeenco.de> 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
>
>
>

Re: Performance improvement patches from Perfloop

[Alex Petrov <al...@coffeenco.de>]

Good point! 

From what I understand even though there’s “loop” in the name it has preceded a current wave of agentic looping. In other words, they use same methodology one would when searching for performance improvements: measurement profiling hypothesis etc., and then go through multiple evaluation stages.

Contributions are not coming with any conditions: agent just posts a patch, and all associated documentation and hypothesis is freely available. 

From what I understand, mentioning that X has found an issue in an open source project is ok (similar to how a researcher can claim a found issue); that of course can’t imply that Cassandra logo can be used in vendor materials. Thank you for pointing that out.

On Wed, Jul 8, 2026, at 9:55 PM, C. Scott Andreas wrote:
> 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 <al...@coffeenco.de> 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

Re: Performance improvement patches from Perfloop

["C. Scott Andreas" <sc...@paradoxica.net>]

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 <al...@coffeenco.de> 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

Re: Performance improvement patches from Perfloop

[Dmitry Konstantinov <ne...@gmail.com>]

Hi Alex,

If the changes are small and localized, then I don't see a big problem. I
can help with the review as a second reviewer if needed, to satisfy the
requirement of having two committers involved. In any case, I'm trying to
keep an eye on all performance-related changes in the codebase.
Regards,
Dmitry

On Wed, 8 Jul 2026 at 13:59, Alex Petrov <al...@coffeenco.de> 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
>


-- 
Dmitry Konstantinov