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 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
