I have to admit I didn’t expect when I raised this to be in a minority ok with *some* stream use :)

Works for me though, definitely preferable to the status quo.



On 7 Jun 2024, at 10:10, Aleksey Yeshchenko <alek...@apple.com> wrote:

Ban in all new non-test code seems like the most pragmatic approach to me as well.

On 7 Jun 2024, at 06:32, Jordan West <jw...@apache.org> wrote:

Similarly in the "don't use them in the main project but am ok with tests" camp

On Thu, Jun 6, 2024 at 4:46 AM Štefan Miklošovič <stefan.mikloso...@gmail.com> wrote:
I have created 


to gather all your ideas about what to remove. If you stumble upon some code which is susceptible to rewriting, just put it there.

On Wed, Jun 5, 2024 at 6:35 PM <shailajako...@icloud.com> wrote:
I would like to vote for banning streams in all non-test code. It may not be easy for new contributors to distinguish between hot path and non-hot path. So would be great if we can simply block them in non-test code and update codestyle to detect the usage.


On Jun 4, 2024, at 6:26 PM, Josh McKenzie <jmcken...@apache.org> wrote:

I'm in the "ban in non-test cases, allow in tests" camp. Can sometimes make things more expressive and concise.

On Mon, Jun 3, 2024, at 12:07 PM, Sam wrote:
Added.

Here is the 'after' profile

<image.png>

On Sun, 2 Jun 2024 at 20:50, Mick Semb Wever <m...@apache.org> wrote:
 
On profiling a 90% write workload I found StorageProxy::updateCoordinatorWriteLatencyTableMetric to be a hot-path, consuming between 15-20% of ModificationStatement::executeWithoutCondition cycles.


Ouch.  Ok, I've no idea what constitutes an ok "slow path" now…

Sam, can you also share in the ticket the easy-cass-stress profile you used please.


Reply via email to