私のチームは Ruby で MMO サーバーに取り組んでおり、計算量の多い操作を C 拡張に移行することにしました。その取り組みの一環として、実際のデータ ストレージを C に移動しました (Data_Get_Struct などを使用)。したがって、たとえば、各 Ruby「Zone」オブジェクトには、実際のバイナリ データが格納される「ZoneKernel::Zone」C 構造体が関連付けられています。
基本的に、これはひどい考えなのかどうか疑問に思っています。私は Ruby の内部構造にあまり詳しくありませんが、親 Zone が Ruby 側のメモリ内にとどまっている限り (したがって、C データのガベージ コレクションを防ぎます)、データは問題ないように思われます。
1 つの注意点は、サーバーをクラッシュさせる半定期的な「スタック整合性エラー」が発生していることです。これは、関連するメモリの問題のように思われます (庭のさまざまな segfault ではなく)。 、私もそれをいただければ幸いです！
機能するドキュメントにData_Wrap_Struct(klass, mark, free, ptr)記載されているように：
引数は、ポインタの
free割り当てを解放する関数です。これがの場合-1、ポインタはただ解放されます。これらの
mark/free関数は、GC の実行中に呼び出されます。
対応する Ruby オブジェクトがファイナライズされると、ラップされたネイティブ構造は自動的に解放されます。それが起こるまで、手動で行わない限り、データは解放されません。
C 拡張機能を記述しても、パフォーマンスが向上することは保証されませんが、ほとんどの場合、コードの複雑さが増します。パフォーマンスの向上を測定するためにサーバーをプロファイリングし、Zone可能であれば純粋な Ruby でクラスを開発します。
一般に、ソースの外部で変更される可能性のあるデータはすべて保持するのが好きです。YAMLまたはデータベースからロードすると、再コンパイルしなくても、データを心ゆくまで微調整できます。明らかに、コンパイル時間とロード時間が速い場合、それはそれほど大きな問題ではありませんが、それでも2つを分離することは良い考えです。
YAMLは標準形式であるため、任意の数の言語から同じファイルにアクセスできるため、私はYAMLを好みます。より速く/よりスマートに見えるものに応じて、C側またはRuby側に直接ロードできます。