Re: [DISCUSS] Stream Pipelines on hot paths

+1 and I am happy to go over streams and at least map where we are at to see what could be done about that. As David mentioned, the main problem is to distinguish what counts as a hot path and what not. On Thu, May 30, 2024 at 6:29 PM Benedict wrote: > Since it’s related to the logging discussio

Re: [DISCUSS] Stream Pipelines on hot paths

My concept of hot path is simply anything we can expect to be called frequently enough in normal operation that it might show up in a profiler. If it’s a library method then it’s reasonable to assume it should be able to be used in a hot path unless clearly labelled otherwise. In my view this inclu

Re: [DISCUSS] Stream Pipelines on hot paths

+1 on avoiding streams in hot paths On 31/5/24 9:48, Benedict wrote: My concept of hot path is simply anything we can expect to be called frequently enough in normal operation that it might show up in a profiler. If it’s a library method then it’s reasonable to assume it should be able to be u

Re: [DISCUSS] Stream Pipelines on hot paths

My concept of hot path is simply anything we can expect to be called frequently enough in normal operation that it might show up in a profiler. If it’s a library method then it’s reasonable to assume it should be able to be used in a hot path unless clearly labelled otherwise. In fact, I’d say the

Re: [DISCUSS] Stream Pipelines on hot paths

For me the definition of hot path is too vague. We had arguments with Berenger multiple times and it is more a waste of time than anything else at the end. If we are truly concerned about stream efficiency then we should simply forbid them. That will avoid lengthy discussions about what constitute

Re: [DISCUSS] Stream Pipelines on hot paths

+1 to either forbid them entirely or not at all. pt., 31 maj 2024, 16:05 użytkownik Benjamin Lerer napisał: > For me the definition of hot path is too vague. We had arguments with > Berenger multiple times and it is more a waste of time than anything else > at the end. If we are truly concerned

Re: [DISCUSS] Stream Pipelines on hot paths

I think I have already proposed a simple solution to this problem on the thread: if anyone says it’s a hot path (and cannot be persuaded otherwise), it should be treated as such. Saves argument, but permits an easy escape hatch if everyone agrees with minimal discussion. I think this is a good

Re: [DISCUSS] Stream Pipelines on hot paths

+1 to forbidding Stream usage entirely; the convenience of using them outside of hot paths is less than the burden of figuring out whether or not a particular path is hot. Even for reviewers it can be difficult to tell whether a particular path is hot; hard-to-diagnose bugs like CASSANDRA-18110

Re: [DISCUSS] Stream Pipelines on hot paths

On Fri, May 31, 2024 at 9:35 AM Abe Ratnofsky wrote: > +1 to forbidding Stream usage entirely; the convenience of using them > outside of hot paths is less than the burden of figuring out whether or not > a particular path is hot. > I think I have most frequently appreciated them in tests, which

Re: [DISCUSS] Stream Pipelines on hot paths

I am cool for forbidding with a callout that tests are ok. I am cool with forbidding in tests as well, but thats just for consistency reasons than anything. > On May 31, 2024, at 8:12 AM, Brandon Williams wrote: > > > On Fri, May 31, 2024 at 9:35 AM Abe Ratnofsky > wrot

Re: [DISCUSS] Stream Pipelines on hot paths

> > I think this is a good general principle for *raising standards* in the > codebase like this: if somebody says something is important, and cannot be > convinced otherwise, then it should generally be treated as important. This > is different from cases where there are simply competing approache

Re: [DISCUSS] Stream Pipelines on hot paths

Usages of them in tests are ok I think. We have a separate checkstyle file for the test code. - - -- --- - - Jacek Lewandowski pt., 31 maj 2024 o 19:14 David Capwell napisał(a): > I am cool for forbidding with a callout that tests are ok. I am cool with > forbidding i

Re: [EXTERNAL] Re: [DISCUSS] Adding experimental vtables and rules around them

Hi, To sum where everyone is coming from: We would like to have features in a stable version of Cassandra which are experimental and are subject to non-backward compatible change. This indicates to me that the feature is not finished and should likely not be included in a stable release. What

Re: [EXTERNAL] Re: [DISCUSS] Adding experimental vtables and rules around them

We have already agreed in the past that having experimental features, behind feature flags, in stable releases is a good thing for keeping those features up to date, for getting feedback from end users, and many others. The question here is about how we ensure that end users are aware something i

[DISCUSS] CEP-42: Constraints Framework

Hello everyone, I am proposing this CEP: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework And I’m looking for feedback from the community. Thanks a lot! Bernardo