2

protobuf-net を使用して、ディープ オブジェクト グラフをシリアライズおよびデシリアライズしています。これらのグラフの一部のメンバーは、いくつかのオブジェクトに対する多対 1 の関係の場合と同様に、実際には多くのグラフにわたって何度も繰り返されます。たとえば、Saleオブジェクトはグラフであり、そのStoreメンバー (場合によってはそれ自体がサブグラフ) は 10 の可能なストアのうちの 1 つにすぎないため、多くのメッセージで何度も繰り返されます ( Saleグラフ）。

これらのオブジェクトのシリアライゼーションを何らかの方法でキャッシュできれば、明らかなパフォーマンス上の利点を得ることができます。理想的には、RuntimeModelに、特定の型 (この場合はStore ) をサロゲートのように拡張ポイントを通じて処理する必要があることを伝えたいと考えていますが、生のシリアル化バイトを提供することはできます。

私たちの制約の 1 つは、これらの "フック" (Python クライアントのスクリュー パフォーマンスの最適化!) なしで、他のプラットフォーム (Python など) のクライアントが直接解析できるようにするために、生成されたメッセージは引き続き protobuf-net と互換性がある必要があるということです。

サロゲートを調べましたが、サロゲートが生成するもの (この場合はバイト[] 配列) は (ご想像のとおり) その型として (つまり、バイト[] 配列として) シリアル化され ます。したがって、Python クライアントが期待するStoreオブジェクトと互換性がありません。

また、拡張機能についても調べました。キャッシュされたシリアル化されたStoreを余分なフィールドで何らかの方法でハッキングしたとしても、Python クライアントでは振り出しに戻ります。

このシナリオで使用できる他の拡張メカニズムはありますか?

4

1 に答える 1

1

ああ、面白い。確かに、Pythonの要件は、私が言おうとしていたことを狂わせます（参照追跡）。あなたができることは、最初にそれらをbyte[]（を介して）それぞれにシリアル化しMemoryStream、次にそのデータをbyte[]メンバーとして含めることです（と元のオブジェクトの間に違いはありませbyte[]ん-外部クライアントは違いに気づきません）が、考えは起こりますほとんどの場合、これは、オブジェクトモデルを「現状のまま」維持し、一部のノードを複数回シリアル化するよりも大幅に高速になることはありません（シリアル化はそれほど遅くありません）。

率直に言って、私はそれを別の方法で保存することを検討します-したがって、ストアを子ノードとして保存する代わりに、それらをトップレベルノードとして一度一意に保持し、ルックアップとしていくつかの一意の識別子を保存します（子オブジェクト自体）。ただし、これによってレイアウトが変わります。

いいえ、これをサポートするものは何も組み込まれていません。それがサポートの重要なシナリオであるかどうかはわかりません。

于 2012-08-11T07:39:34.247 に答える