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 hot, code simplicity must be the first priority. I don't want Ignite 3 code to look like Ignite 2 code, where people would iterate over Lists using explicit access by indexes, because it saves them a single Iterator allocation. That's absurd. ср, 8 сент. 2021 г. в 11:43, Pavel Tupitsyn <ptupit...@apache.org>: > 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 thrpt 3 > 7987.016 ± 293.013 ops/ms > * StreamVsLoopBenchmark.loopSum:·gc.alloc.rate thrpt 3 > ≈ 10⁻⁴ MB/sec > * StreamVsLoopBenchmark.loopSum:·gc.count thrpt 3 > ≈ 0 counts > > * StreamVsLoopBenchmark.streamSum thrpt 3 > 1060.244 ± 36.485 ops/ms > * StreamVsLoopBenchmark.streamSum:·gc.alloc.rate thrpt 3 > 315.819 ± 10.844 MB/sec > * StreamVsLoopBenchmark.streamSum:·gc.count thrpt 3 > 55.000 counts > > Loop is several times faster and does not allocate at all. > > 1. Performance is one of the most important features of our product. > 2. Most of our APIs will be on the hot path. > > One can argue about performance differences in real-world scenarios, > but increasing GC pressure just to make the code a little bit nicer is > unacceptable. > > I propose to ban streams usage in the codebase (except for the tests). > > Thoughts, objections? > > [1] https://gist.github.com/ptupitsyn/5934bbbf8f92ac4937e534af9386da97 > -- Sincerely yours, Ivan Bessonov
