它可能会出现明显的是,在计数的元素Stream
需要较长时间的多个元素中有Stream
。 但实际上,
Stream::count
有时可以在一个操作中完成,无论您有多少元素。 阅读本文并了解操作方法。
计数复杂度
Stream::count
终端操作对a中的元素数进行计数
Stream
。 运算的复杂度通常为O(N)
,这意味着子运算的数量与运算中元素的数量成正比。
Stream
。
相反, List::size
方法的复杂度为O(1)
,这意味着无论List
中元素的数量如何, size()
方法都会在恒定时间内返回。 通过运行以下JMH基准可以观察到这一点:
@State (Scope.Benchmark) public class CountBenchmark { private List<Integer> list; @Param ({ "1" , "1000" , "1000000" }) private int size; @Setup public void setup() { list = IntStream.range( 0 , size) .boxed() .collect(toList()); } @Benchmark public long listSize() { return list.size(); } @Benchmark public long listStreamCount() { return list.stream().count(); } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(CountBenchmark. class .getSimpleName()) .mode(Mode.Throughput) .threads(Threads.MAX) .forks( 1 ) .warmupIterations( 5 ) .measurementIterations( 5 ) .build(); new Runner(opt).run(); } }
这在我的笔记本电脑(2015年中的MacBook Pro,2.2 GHz Intel Core i7)上产生了以下输出:
Benchmark (size) Mode Cnt Score Error Units CountBenchmark.listSize 1 thrpt 5 966658591.905 ± 175787129.100 ops/s CountBenchmark.listSize 1000 thrpt 5 862173760.015 ± 293958267.033 ops/s CountBenchmark.listSize 1000000 thrpt 5 879607621.737 ± 107212069.065 ops/s CountBenchmark.listStreamCount 1 thrpt 5 39570790.720 ± 3590270.059 ops/s CountBenchmark.listStreamCount 1000 thrpt 5 30383397.354 ± 10194137.917 ops/s CountBenchmark.listStreamCount 1000000 thrpt 5 398.959 ± 170.737 ops/s
<br>
可以看出, List::size
的吞吐量在很大程度上与List
中元素的数量无关,而Stream::count
的吞吐量随着元素数量的增加而Swift下降。 但是,实际上所有Stream
实现本身总是如此吗?
源感知流
一些流实现实际上知道它们的源,并且可以采用适当的快捷方式并将流操作合并到流源本身中。 这可以极大地提高性能,尤其是对于大型流。 Speedment ORM工具允许将数据库视为Stream对象,并且这些流可以优化许多流操作,如Stream::count
操作,如下面的基准所示。 我已使用开源Sakila示例数据库作为数据输入。 Sakila数据库包含有关租赁电影,艺术家等的全部信息。
@State (Scope.Benchmark) public class SpeedmentCountBenchmark { private Speedment app; RentalManager rentals; private RentalManager rentals; private FilmManager films; @Setup public void setup() { app = new SakilaApplicationBuilder() .withBundle(DataStoreBundle. class ) .withLogging(ApplicationBuilder.LogType.STREAM) .withPassword(ExampleUtil.DEFAULT_PASSWORD) .build(); app.get(DataStoreComponent. class ).ifPresent(DataStoreComponent::load); rentals = app.getOrThrow(RentalManager. class ); films = app.getOrThrow(FilmManager. class ); } @TearDown public void tearDown() { app.close(); } @Benchmark public long rentalsCount() { return rentals.stream().count(); } @Benchmark public long filmsCount() { return films.stream().count(); } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(SpeedmentCountBenchmark. class .getSimpleName()) .mode(Mode.Throughput) .threads(Threads.MAX) .forks( 1 ) .warmupIterations( 5 ) .measurementIterations( 5 ) .build(); new Runner(opt).run(); } }
运行时,将产生以下输出:
Benchmark Mode Cnt Score Error Units SpeedmentCountBenchmark.filmsCount thrpt 5 71037544.648 ± 75915974.254 ops/s SpeedmentCountBenchmark.rentalsCount thrpt 5 69750012.675 ± 37961414.355 ops/s
<br>
<br>
“租赁”表包含10,000行,而“电影”表仅包含1,000行。 但是,它们的Stream::count
操作几乎在同一时间完成。 即使一个表包含一万亿行,它仍然会在相同的经过时间内对元素进行计数。 就这样
Stream::count
实现的复杂度为O(1)
而不是
O(N)
注意:上面的基准测试是通过Speedment的“ DataStore” JVM虚拟机内存加速来运行的。 如果直接对数据库没有加速运行,则响应时间将取决于基础数据库执行“SELECT count(*) FROM film”
查询的能力。
摘要
可以创建在单个操作中对元素进行计数的Stream
实现,而不是对流中的每个元素进行计数。 这可以显着提高性能,尤其是对于具有许多元素的流。
资源资源
Speedment Stream ORM初始化程序: https ://www.speedment.com/initializer/
Sakila: https ://dev.mysql.com/doc/index-other.html或https://hub.docker.com/r/restsql/mysql-sakila
翻译自: https://www.javacodegeeks.com/2019/04/java-stream-count-always-count.html