1

Scala は String 操作を java.lang.String に依存していますが、.intersect などの他のメソッドを追加することで Java 文字列クラスを強化します。Java の int ラッパー (Int) についても同様です。RichInt クラスもあります。

私は次のコードを認識しています：

val stringOne: String = "teststring"
val stringTwo: String = "string"
stringOne.intersect(stringTwo)

メソッド intersect にアクセスできるように、scala コンパイラが stringOne を StringOps クラスにキャストするようにします。

これが深刻な計算コストにつながるのではないかと心配しています。では、これが本当かどうか教えてもらえますか?もしそうなら、この状況を最適化または回避する方法はありますか?

私の質問が理にかなっていることを願っています。私はいくつかの本を読みましたが、これらの懸念に対処するものはありません ありがとう. :)

編集：同様の質問が尋ねられ、ここで回答 されました。誰かが記憶の角度からもこれに対処できれば幸いです

4

1 に答える 1

2

一般に、暗黙的な変換によるパフォーマンスへの影響が生じる可能性があります (たとえば、長い間、.isNaNよりも ~50% 遅くなりjava.lang.Double.isNaNました)。ただし、変換先のクラスが値クラスの場合、JIT コンパイラは残りのオーバーヘッドを簡単に削除できます (通常は何もありません。1 つの暗黙的な変換で別の変換を使用し、別の変換を使用するなどの場合、オーバーヘッドをいくらか保持できます)。 -- JIT コンパイラーは、呼び出しのチェーン全体を削除する前にあきらめます)。

いずれにせよ、それはここでの主な関心事ではありません。 intersectは汎用メソッドであるため、文字列内のすべての文字をボックス化します。のみを取るようにカスタム設計された方法と比較して、それは物事を非常に遅くします（おそらく5倍程度）Char。

これらのことを伝える方法は、Scaladocs を見て、実装がどこにあるかを確認することです。 intersect葉に出ていない ( StringOps); SeqLikeそれは文字について具体的に何も知らないにまでさかのぼります。(まあ、ソース コードやベンチマークを確認する必要があることを確認する必要がありますが、通常は Scaladoc にリストされている定義サイトから良いアイデアを得ることができます。)

于 2013-09-25T17:43:37.187 に答える