To summarize:
We don't ban streams but use them with caution, avoid on hot paths. The
decision is up to the author and reviewer.
Thanks for the discussion!
On Mon, Sep 13, 2021 at 10:25 PM Pavel Tupitsyn
wrote:
> Konstantin,
>
> > The performance penalty ... is 25%, not 8 times
> I'm sure you a
Konstantin,
> The performance penalty ... is 25%, not 8 times
I'm sure you are using a different JDK, I'm on OpenJDK 11 as listed in the
gist.
Ivan,
> rewrite it using BlackHole
I did, updated the gist, the results are the same.
On Thu, Sep 9, 2021 at 11:12 AM Ilya Kasnacheev
wrote:
> Hello
Hello!
-1 Let's not ban Java Streams, for the reasons already listed.
Regards,
--
Ilya Kasnacheev
чт, 9 сент. 2021 г. в 10:59, Ivan Daschinsky :
> Few words about the topic.
> There is a disease, quite common in the java community -- it is called the
> streamosis.
> But, to be honest, afear o
Few words about the topic.
There is a disease, quite common in the java community -- it is called the
streamosis.
But, to be honest, afear of streams is also not good.
As for me, sometimes rewriting code completely with simple loops often
makes it more readable, understandable and usually faster.
To be honest, Pavel, your benchmark is not quite correct. Please, rewrite
it using BlackHole
чт, 9 сент. 2021 г. в 10:28, Nikolay Izhikov :
> +1 to ban Streams usage.
>
>
>
> > 9 сент. 2021 г., в 02:59, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >
> > Pavel,
> >
> > Quit
+1 to ban Streams usage.
> 9 сент. 2021 г., в 02:59, Valentin Kulichenko
> написал(а):
>
> Pavel,
>
> Quite frankly, I think we used to lean into performance too much. We
> generally preferred it over data consistency, project modularity and code
> readability. Performance, of course, plays
Pavel,
Quite frankly, I think we used to lean into performance too much. We
generally preferred it over data consistency, project modularity and code
readability. Performance, of course, plays a very important rule in Ignite,
but it's possible to overdo anything.
There are certainly parts of the
Alexander, Ivan,
> not very productive to assume that 100% of your code is
> on the hot path
That is exactly what we should be doing.
When I joined Ignite community 6 years ago, this was the prevalent mindset.
I'm not sure which part of Ignite can be considered "not on a hot path".
Create/alter
I don't think we should ban anything. Streams API is just a tool in the
toolbox - it should be used appropriately. It's up to the contributor and
reviewer(s) to identify whether a particular usage might cause performance
issues.
-Val
On Wed, Sep 8, 2021 at 8:01 AM Alexander Polovtcev
wrote:
> -
-1
I think that it is not very productive to assume that 100% of your code is
on the hot path, it would be impossible to write and maintain. Humans are
not very good at guessing where the performance bottlenecks are, so the
performance of the possible hot paths should be measured first and only
the
Does not this trivial strategy work for us? https://wiki.c2.com/?OptimizeLater
2021-09-08 13:52 GMT+03:00, Andrey Gura :
> Agree that any additional object creation on a hot path could be a
> problem. So hot path should not contain stream API and any other
> potentially problem code (e.g. iterator
Agree that any additional object creation on a hot path could be a
problem. So hot path should not contain stream API and any other
potentially problem code (e.g. iterator instead of for by index).
On Wed, Sep 8, 2021 at 1:45 PM Pavel Tupitsyn wrote:
>
> Ok, maybe a total ban is overkill, but rig
Ok, maybe a total ban is overkill, but right now streams are used even on
some hot paths like getAllAsync [1].
Another issue is that Collectors.toList() and other variants don't accept
capacity, and we end up with unnecessary reallocations of underlying arrays.
[1]
https://github.com/apache/ignit
Hi!
Agree with Ivan that it’s an overkill. Code readability and maintainability
should have
the same priority as the performance (with some exceptions of course).
BTW the result of your benchmark looks quite strange. The performance penalty on
my laptop (Core i7 9750H, 6 cores up to 4.50 GHz) is
-1 for "banning" streams.
Fully agree with Ivan B.
2021-09-08 12:23 GMT+03:00, Ivan Bessonov :
> Hello Igniters,
>
> I object, banning streams is an overkill. I would argue that most of the
> code
> is not on hot paths and that allocations in TLAB don't create much pressure
> on GC.
>
> Streams m
Hello Igniters,
I object, banning streams is an overkill. I would argue that most of the
code
is not on hot paths and that allocations in TLAB don't create much pressure
on GC.
Streams must be used cautiously, developers should know whether they
write hot methods or not. And if methods are not ho
Pavel, thanks !
And what about stream usage not in a hot path ? I.e. create\drop table
operation, may be such a cases will leave for committer\contributor
consideration ?
>Igniters,
>
>Java streams are known to be slower and cause more GC pressure than an
>equivalent loop.
>Below is a simple f
Igniters,
Java streams are known to be slower and cause more GC pressure than an
equivalent loop.
Below is a simple filter/map/reduce scenario (code [1]):
* Benchmark Mode Cnt
Score Error Units
* StreamVsLoopBenchmark.loopSum
18 matches
Mail list logo
