-1 for "banning" streams. Fully agree with Ivan B.
2021-09-08 12:23 GMT+03:00, Ivan Bessonov <bessonov...@gmail.com>: > 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 > -- Best regards, Ivan Pavlukhin
