I think the value of this conversation is surfacing the problem with
streams and raising awareness. If you use them in some test that sounds
good to me.
Same happens with some loops that trigger iterators that might
inadvertently hydrate lots of unnecessary stuff into memory etc. Keeping
yourself to 'classic' loops is not that bad of a decision imo.
On 7/6/24 11:27, Štefan Miklošovič wrote:
I think it makes sense to use streams to make the life easier for a
dev when constructing some log messages or something like that in
clearly not hot paths. Nothing wrong with that ...
Collectors.joining(", ") and that kind of stuff. I do not think that
doing this aggressively and "orthodoxly" is necessary.
On Fri, Jun 7, 2024 at 11:22 AM Benedict <bened...@apache.org> wrote:
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
https://issues.apache.org/jira/browse/CASSANDRA-19673
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.
https://github.com/apache/cassandra/pull/3344
<image.png>
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.
