Kotlinの隠れたコストについてのベンチマーク | POSTD

@BladeCoder が書いた Kotlinの隠れたコストの調査 という一連のブログ記事は、ある Kotlin 構文にどのように隠れたコストがあるのかを説明しました。 実際の隠れたコストは、普通、不可視オブジェクトのインスタンス化やプリミティブ値のボクシング／アンボクシングに起因します。これらのコストは、Kotlinコンパイラがどのように上記の構文をJVMのバイトコードに変換するのかを理解していない開発者には特に見えづらいのです。 しかし、何らかの数字を示さずに隠れたコストの話をするだけでは、実際にどのくらいコストのことを心配すべきなのかという疑問が湧いてきます。コードベースのいたるところで、これらのコストを考慮すべきでしょうか？あるKotlin構文は単に全面的に禁止されるべきでしょうか？あるいは、最も範囲の狭い内部ループの中でだけ考慮されるべきでしょうか？ さらに挑発的な言い方をすれば

[tlync]

Android 2.x 時代の Enum 使わない方がいいよ問題を彷彿とさせる。計算量の多いアルゴリズムの開発などでない限り、JVM 上の実行速度より I/O による時間が大半なので、コードのメンテナビリティをとるな

[moccos_info]

元記事で脅されていたほどではないが、いくつか明確な罠ありと。C#でも性能必要なときはLINQ禁止等々色々あるし、現実ってこんなものか。

[habarhaba]

どうせ皆検証しないといけないからこういう記事助かるな―

[jumperson]

Kotlinのベンチマーク。いくつか気をつけるべき点があった。

[vanbraam]

この記事及びベンチマークは,別の人物が推測で書いた"隠れたコスト"の実相を明らかにし,風評被害から守るのが目的.殆どのケースで"隠れたコスト"が存在しない事が明らかになり,Kotlinの評判が守られた

[masayoshinym]

それくらいなら許容できるな…と思ってしまう。

[kikuchy]

メンテナビリティとのトレードオフかな。可変長引数への配列展開は必要になるケースがあまりない気がするし、規約で禁止しても良いのかもしれない。

[uzimith]

そんな問題なさそう

[turanukimaru]

forEach遅いのかーわざわざforEachで書き直してたのに

[mizoguche]

Javaより速くなるのがあるの面白い／想定してるユースケースでそんなにパフォーマンスに問題が出そうなのはない

[xbs2r]

パフォーマンスを理由に躊躇う必要はなさそうだ

[KSKSKSKS2]

思った以上にKotlin速いな、という印象