問題タブ [immutablelist]

ImmutableListNuGet パッケージMicrosoft.Bcl.Immutableバージョン 1.0.34 および 1.1.22-betaから Microsoft の予期しないパフォーマンスが発生する

不変リストからアイテムを削除すると、パフォーマンスが非常に遅くなります。20000 個の整数ImmutableList値 (1...20000) を含む場合、値 20000 から 1 への削除を開始すると、リストからすべてのアイテムを削除するのに約 52 秒かかります。各削除操作の後にリストのコピーを作成するジェネリックList<T>で同じことを行うと、約500ミリ秒かかります。

ImmutableListはジェネリックをコピーするよりも速いと思っていたので、これらの結果には少し驚きましたList<T>が、おそらくこれは予想されることでしょうか?

サンプルコード

アップデート

ImmutableList通常の foreach ループのように、の先頭からアイテムを削除すると、パフォーマンスが大幅に向上します。すべてのアイテムを削除するのにかかる時間は 100 ミリ秒未満です。これはすべてのシナリオでできることではありませんが、知っておくとよいでしょう。

を使用して配列からリストを作成するjava.util.Arrays.asList()と、リストは不変になります。List(またはSetまたはMap) の基本的な目的が動的なサイズを持ち、自由に要素を追加、削除できるようにすることである場合に、なぜ不変リストを作成する必要があるのか​​ を知りたいだけです。固定サイズのデータ​​構造が必要な場合は Array を使用し、動的なデータ構造が必要な場合はListor SetorMapなどを使用します。では、不変リストを持つ目的は何でしょうか? 課題に取り組んでいるときにこれに出くわしました。

Microsoft からリリースされたばかりの .Net コア プロジェクトのコードを少し読んでいます。( https://github.com/Microsoft/dotnet ) .Net コア チームがどのように実装したかを見ることができてうれしいです。彼らのコードから 1 つまたは 2 つのことを学べるかもしれないと思いました。

私の注意を引いたのは、Clear() の関数がどのように実装されているかということです。

新しいリストを作成すると、空のプロパティに新しいリストが入力され、 Clear 関数が実行されたときに返されるようです。これにより、古いリストを逆参照し (たとえば、var students = students.Clear();)、GC が古いリストをクリアできるようにします。

これらはすべて非常にクールですが、理解できないのは、Empty プロパティの上記の定義が無限ループを引き起こさないのはなぜですか? 新しいリストを作成するたびに、実際には2つ作成される場合、空のプロパティリスト用にインスタンス化された新しいImmutableListも、空のプロパティ用に別のインスタンスをインスタンス化するなどということではないでしょうか?

誰か説明してくれませんか？また、上記の私の理解が正しくない場合は、修正してください。

不変変数: 変更された場合に元のバージョンを格納する変数のタイプ。質問: Python でその変数の古いバージョンにアクセスするにはどうすればよいですか? またはJavaで？または、この「永続的なデータ構造」をサポートする他の言語はありますか? または、不変変数の定義について間違っていますか?

変数を変更した後、 pythonとしましょう:

の古い値を取得するにはどうすればよいvar nameですか?

注: この質問は、重複としてマークされている質問とは異なります。この質問は変数のメモリ位置に関するものであり、もう 1 つの質問は変数のスコープに関するものです。

Google の ImmutableList クラスを使用していますhttp://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/ImmutableList.html

既存の ImmutableList と追加の要素 (同じ型) を取り、古い要素と新しい要素を含む新しいImmutableList を返すメソッドを探しています。

おそらく、ドキュメントに明らかな何かが欠けていますか？

メソッドを使用してグアバImmutableListを作成ofし、渡されたオブジェクトに基づいて正しいジェネリック型を取得できます。

ただし、パラメーターのないメソッドはofジェネリック型を推測できず、ImmutableList<Object>.

ImmutableList満たすために空を作成するにはどうすればよいList<Foo>ですか?

不変になる前は、多くの API でIEnumerableが頼りになるインターフェイスでした。これには、API が渡されたオブジェクトの実際の型に影響されないという利点があったためです。

もちろん、これには少なくとも 2 つの欠点があります。

1. API の背後にあるコードは、 collectionOfThingsの不変性に依存できず、「コレクションが変更されました」例外が発生したり、その他の微妙な問題が発生したりする可能性があります。

2. collectionOfThingsが実際のコレクションなのか、単に遅延クエリなのかはわかりません。それが実際のコレクションであると想定し、そうでない場合、複数の列挙を実行することでパフォーマンスが低下するリスクがあります。それが遅延クエリであり、実際には実際のコレクションであると仮定した場合、それをローカル リストまたは他の凍結されたコレクションに変換すると、最初の問題から保護するのに役立ちますが、不必要なコストが発生します (「ToList」操作の実行中に競合状態が依然として発生します)。 ）。明らかに、これをチェックして「正しいこと」を実行するために少量のコードを作成することはできますが、これは面倒な余分な混乱です。

命名規則を使用する以外に、これに対処するための満足のいくパターンを見つけたことがないことを認めなければなりません。実用的なアプローチは、 IEnumerableがコレクションを渡すための最も摩擦の少ないアプローチであると思われましたが、欠点はありました。

現在、不変のコレクションにより、状況は大幅に改善されています...

コレクションが変更されるリスクがなくなり、複数の列挙によるパフォーマンスへの影響についてあいまいさがなくなりました。

ただし、ImmutableListを渡す必要があるため、明らかに API の柔軟性が失われています。私たちのクライアントが他の種類の列挙可能な不変コレクションを持っている場合、それを列挙することだけが目的であっても、それを消費するにはImmutableListにコピーする必要があります。

理想的には、次のようなインターフェースを使用できます

しかしもちろん、インターフェイスは、慣習による場合を除いて、不変性などのセマンティクスを強制することはできません。

基本クラスを使用するとうまくいくかもしれません

ただし、サブクラスが可変性を導入しないように、封印されていない不変クラスを作成することは悪い形式と見なされます。いずれにせよ、これは BCL では行われていません。

または、API で IEnumerable を使用し続け、命名規則を使用して、コードが渡される不変のコレクションに依存していることを明確にすることもできます。

だから...私の質問は、不変のコレクションを渡すときにどのパターンが最適と考えられるかということです? ImmutableListは、不変性を使い始めたら「新しいIEnumerable 」ですか、それとももっと良い方法がありますか?

アップデート

IReadOnlyCollection (以下の Yuval Itzchakov によって提案されています) はIEnumerableよりも明らかに改善されていますが、コレクション内の制御されていない変更からコンシューマーを完全に保護することはできません。Roslyn コードベースが (主にImmutableArrayを介して) 不変性を多用し、これらを他のメソッドに渡すときに明示的な型指定を使用しているように見えることは注目に値しますが、 ImmutableListがIEnumerableを受け入れるメソッドに渡される場所がいくつかあります。