看到一個(gè)評論,里面提到了list.sort()和list.strem().sorted()排序的差異。
說到list.sort()排序比stream().sorted()排序性能更好。
但沒說到為什么。
有朋友也提到了這一點(diǎn)。
本文重新開始,先問是不是,再問為什么。
真的更好嗎?
先簡單寫個(gè) demo。
ListuserList=newArrayList<>(); Randomrand=newRandom(); for(inti=0;i10000?;?i++)?{ ????????userList.add(rand.nextInt(1000)); ????} ????List userList2=newArrayList<>(); userList2.addAll(userList); LongstartTime1=System.currentTimeMillis(); userList2.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList()); System.out.println("stream.sort耗時(shí):"+(System.currentTimeMillis()-startTime1)+"ms"); LongstartTime=System.currentTimeMillis(); userList.sort(Comparator.comparing(Integer::intValue)); System.out.println("List.sort()耗時(shí):"+(System.currentTimeMillis()-startTime)+"ms");
輸出
stream.sort耗時(shí):62ms List.sort()耗時(shí):7ms
由此可見 list 原生排序性能更好。
能證明嗎?
不一定吧。
再把 demo 變換一下,先輸出stream.sort。
ListuserList=newArrayList<>(); Randomrand=newRandom(); for(inti=0;i10000?;?i++)?{ ????userList.add(rand.nextInt(1000)); } List userList2=newArrayList<>(); userList2.addAll(userList); LongstartTime=System.currentTimeMillis(); userList.sort(Comparator.comparing(Integer::intValue)); System.out.println("List.sort()耗時(shí):"+(System.currentTimeMillis()-startTime)+"ms"); LongstartTime1=System.currentTimeMillis(); userList2.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList()); System.out.println("stream.sort耗時(shí):"+(System.currentTimeMillis()-startTime1)+"ms");
此時(shí)輸出變成了。
List.sort()耗時(shí):68ms stream.sort耗時(shí):13ms
這能證明上面的結(jié)論錯誤了嗎?
都不能。
兩種方式都不能證明到底誰更快。
使用這種方式在很多場景下是不夠的,某些場景下,JVM 會對代碼進(jìn)行 JIT 編譯和內(nèi)聯(lián)優(yōu)化。
LongstartTime=System.currentTimeMillis(); ... System.currentTimeMillis()-startTime
此時(shí),代碼優(yōu)化前后執(zhí)行的結(jié)果就會非常大。
基準(zhǔn)測試是指通過設(shè)計(jì)科學(xué)的測試方法、測試工具和測試系統(tǒng),實(shí)現(xiàn)對一類測試對象的某項(xiàng)性能指標(biāo)進(jìn)行定量的和可對比的測試。
基準(zhǔn)測試使得被測試代碼獲得足夠預(yù)熱,讓被測試代碼得到充分的 JIT 編譯和優(yōu)化。
下面是通過 JMH 做一下基準(zhǔn)測試,分別測試集合大小在 100,10000,100000 時(shí)兩種排序方式的性能差異。
importorg.openjdk.jmh.annotations.*; importorg.openjdk.jmh.infra.Blackhole; importorg.openjdk.jmh.results.format.ResultFormatType; importorg.openjdk.jmh.runner.Runner; importorg.openjdk.jmh.runner.RunnerException; importorg.openjdk.jmh.runner.options.Options; importorg.openjdk.jmh.runner.options.OptionsBuilder; importjava.util.*; importjava.util.concurrent.ThreadLocalRandom; importjava.util.concurrent.TimeUnit; importjava.util.stream.Collectors; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MICROSECONDS) @Warmup(iterations=2,time=1) @Measurement(iterations=5,time=5) @Fork(1) @State(Scope.Thread) publicclassSortBenchmark{ @Param(value={"100","10000","100000"}) privateintoperationSize; privatestaticListarrayList; publicstaticvoidmain(String[]args)throwsRunnerException{ //啟動基準(zhǔn)測試 Optionsopt=newOptionsBuilder() .include(SortBenchmark.class.getSimpleName()) .result("SortBenchmark.json") .mode(Mode.All) .resultFormat(ResultFormatType.JSON) .build(); newRunner(opt).run(); } @Setup publicvoidinit(){ arrayList=newArrayList<>(); Randomrandom=newRandom(); for(inti=0;ie)); blackhole.consume(arrayList); } @Benchmark publicvoidstreamSorted(Blackholeblackhole){ arrayList=arrayList.stream().sorted(Comparator.comparing(e->e)).collect(Collectors.toList()); blackhole.consume(arrayList); } }
性能測試結(jié)果:
可以看到,list.sort()效率確實(shí)比stream().sorted()要好。
為什么更好?
流本身的損耗
java 的 stream 讓我們可以在應(yīng)用層就可以高效地實(shí)現(xiàn)類似數(shù)據(jù)庫 SQL 的聚合操作了,它可以讓代碼更加簡潔優(yōu)雅。
但是,假設(shè)我們要對一個(gè) list 排序,得先把 list 轉(zhuǎn)成 stream 流,排序完成后需要將數(shù)據(jù)收集起來重新形成 list,這部份額外的開銷有多大呢?
我們可以通過以下代碼來進(jìn)行基準(zhǔn)測試。
importorg.openjdk.jmh.annotations.*; importorg.openjdk.jmh.infra.Blackhole; importorg.openjdk.jmh.results.format.ResultFormatType; importorg.openjdk.jmh.runner.Runner; importorg.openjdk.jmh.runner.RunnerException; importorg.openjdk.jmh.runner.options.Options; importorg.openjdk.jmh.runner.options.OptionsBuilder; importjava.util.ArrayList; importjava.util.Comparator; importjava.util.List; importjava.util.Random; importjava.util.concurrent.TimeUnit; importjava.util.stream.Collectors; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MICROSECONDS) @Warmup(iterations=2,time=1) @Measurement(iterations=5,time=5) @Fork(1) @State(Scope.Thread) publicclassSortBenchmark3{ @Param(value={"100","10000"}) privateintoperationSize;//操作次數(shù) privatestaticListarrayList; publicstaticvoidmain(String[]args)throwsRunnerException{ //啟動基準(zhǔn)測試 Optionsopt=newOptionsBuilder() .include(SortBenchmark3.class.getSimpleName())//要導(dǎo)入的測試類 .result("SortBenchmark3.json") .mode(Mode.All) .resultFormat(ResultFormatType.JSON) .build(); newRunner(opt).run();//執(zhí)行測試 } @Setup publicvoidinit(){ //啟動執(zhí)行事件 arrayList=newArrayList<>(); Randomrandom=newRandom(); for(inti=0;i
方法 stream 測試將一個(gè)集合轉(zhuǎn)為流再收集回來的耗時(shí)。
方法 sort 測試將一個(gè)集合轉(zhuǎn)為流再排序再收集回來的全過程耗時(shí)。
測試結(jié)果如下:
可以發(fā)現(xiàn),集合轉(zhuǎn)為流再收集回來的過程,肯定會耗時(shí),但是它占全過程的比率并不算高。
因此,這部只能說是小部份的原因。
排序過程
我們可以通過以下源碼很直觀的看到。
1 begin方法初始化一個(gè)數(shù)組。
2 accept 接收上游數(shù)據(jù)。
3 end 方法開始進(jìn)行排序。
這里第 3 步直接調(diào)用了原生的排序方法,完成排序后,第 4 步,遍歷向下游發(fā)送數(shù)據(jù)。
所以通過源碼,我們也能很明顯地看到,stream()排序所需時(shí)間肯定是 > 原生排序時(shí)間。
只不過,這里要量化地搞明白,到底多出了多少,這里得去編譯 jdk 源碼,在第 3 步前后將時(shí)間打印出來。
這一步我就不做了。
感興趣的朋友可以去測一下。
不過我覺得這兩點(diǎn)也能很好地回答,為什么list.sort()比Stream().sorted()更快。
補(bǔ)充說明:
本文說的 stream() 流指的是串行流,而不是并行流。
絕大多數(shù)場景下,幾百幾千幾萬的數(shù)據(jù),開心就好,怎么方便怎么用,沒有必要去計(jì)較這點(diǎn)性能差異。
審核編輯:劉清
-
SQL
+關(guān)注
關(guān)注
1文章
750瀏覽量
43900 -
JAVA語言
+關(guān)注
關(guān)注
0文章
138瀏覽量
20027 -
JVM
+關(guān)注
關(guān)注
0文章
155瀏覽量
12168
原文標(biāo)題:為什么list.sort()比Stream().sorted()更快?
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論