アカウント名:
パスワード:
文字列にあわせて新しい領域をとるために遅いことはわかりますが、Javaのほうが遅いというのは、ヒープ領域が小さすぎて、GCが多数回動いているからでしょうか？
論文のソースコードがダメダメですね。遅くて当たり前です。JavaではStringは変更不可のオブジェクトなので文字列を効率よく編集するにはStringBuilderを使うのが常識になってます。
String concatString = "";for (int i=0; i < numIter; i++) { concatString += addString;}
上のコードは次のコードと等価です。毎回大量のオブジェクトを生成して破棄する富豪的なコードなのでGCが大量に発生して最悪のパフォーマンスになっていますね。
String concatString = "";for (int i = 0; i < n
うん、みんな知ってる
>論文には「JavaではStringBuilderやStringBufferといったミュータブルなデータ型を使用すれば結果が大幅に改善する」といった記述もある
さらにいうと、リバースコンパイラでチェックしたけど、最近のコンパイラなら hoge += fuga 的にシンプルに記述していれば、勝手にテンポラリな StringBuilder に置き換えてくれる。
# 当然、StringBuffer とか使って現在では微妙な最適化した古いコードは、コンパイラで最適化してくれない。# 何でも感でも人間が最適化するのは考え物ですね。
Javaの場合、実行中にさらに最適化される可能性もあるし。Pythonの場合でも処理系の実装によっては同様の最適化が可能と思う。プログラマー同士の雑談レベルの話題を論文にしたことに意味はあるのだろうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
Javaのヒープ領域 (スコア:2)
文字列にあわせて新しい領域をとるために遅いことはわかりますが、Javaのほうが遅いというのは、ヒープ領域が小さすぎて、
GCが多数回動いているからでしょうか？
Re: (スコア:0, 参考になる)
論文のソースコードがダメダメですね。遅くて当たり前です。
JavaではStringは変更不可のオブジェクトなので文字列を効率よく編集するにはStringBuilderを使うのが常識になってます。
String concatString = "";
for (int i=0; i < numIter; i++) {
concatString += addString;
}
上のコードは次のコードと等価です。毎回大量のオブジェクトを生成して破棄する富豪的なコードなのでGCが大量に発生して最悪のパフォーマンスになっていますね。
String concatString = "";
for (int i = 0; i < n
Re: (スコア:1)
うん、みんな知ってる
>論文には「JavaではStringBuilderやStringBufferといったミュータブルなデータ型を使用すれば結果が大幅に改善する」といった記述もある
Re:Javaのヒープ領域 (スコア:4, 参考になる)
さらにいうと、リバースコンパイラでチェックしたけど、
最近のコンパイラなら hoge += fuga 的にシンプルに記述していれば、
勝手にテンポラリな StringBuilder に置き換えてくれる。
# 当然、StringBuffer とか使って現在では微妙な最適化した古いコードは、コンパイラで最適化してくれない。
# 何でも感でも人間が最適化するのは考え物ですね。
Re: (スコア:0)
Javaの場合、実行中にさらに最適化される可能性もあるし。
Pythonの場合でも処理系の実装によっては同様の最適化が可能と思う。
プログラマー同士の雑談レベルの話題を論文にしたことに意味はあるのだろうか。