この間プログラムのリソーステーブルを最適化するために、少し研究、このレコードでは、いくつかの成功を収めて考え。
共有メモリ内のリソーステーブルの上に私たちのサーバー：それを説明するための最初のいくつかの背景。この主な理由は、（本館リソーステーブル再び引き出さとリソーステーブルプロセスを再構築コアに必要としないときということと、その後で、このようなハッシュテーブルを構築するよう、インデックスクエリのデータ構造を構築することであるがHeroID問い合わせヒーローに応じてそれを設定するために使用されます種）。次に、リソーステーブルと共有メモリマシン上で複数のプロセスを可能にするメカニズムがあるかどうか、だと思うので、当然、同じマシン上で複数のプロセスを導入する可能性を検討？
より直感的なアイデアは、複数のプロセスが共有メモリリソーステーブルの同じ部分に掛けていることです。そうすることで、実際に共有メモリの目的を達成するが、リソーステーブルのリロードの状況を考慮する必要がありますすることができます。リロード動作を書き込む際に、このメモリはするだろう、と私たちは、かつて多くの並行性の問題を読んで書き込みがあることを知っています。この実施形態は、したがって、まだ並行性の問題に対処するための仕組みを導入する必要があります。一般的な例では、新しいリソース・テーブル・メモリへの良好なビルド時のスイッチの後に、ダブルバッファです。私はいくつかのチームは本当に手の込んだない具体的には、やっている学びました。
コード生成技術を使用し、C ++のコードにリソーステーブルを完全ガイド：私の考える方法がこれです。クエリ構造で使用されるすべてのデータは、自動コード生成を介して行われ、そしてそれは静的良好構築コンパイル。このメモリは、プロセスの実行に直接ロードすることができ、プロセスがサービスから構築されたリソーステーブルに以前のように実行する必要はありません。したがって、このメモリは、手動で、共有メモリ上に置く必要はありません。コアプロセスの後、次いで、テーブルメモリにプルアップがアンロードされるリソースであり、そして次のページフォールトを使用することにより、再びメモリにロードされたトリガするであろう。同じマシン上の共有メモリを行うためには、リソーステーブルの動的ライブラリにパッケージ化することができます。だから、仕事の共有メモリのこの作品は、自然にそれを行うには、オペレーティング・システムにプッシュ。
このアプローチにはいくつかの利点があります。私は、これは（：P私も、以前のブログで述べた）一回問題解決のアプローチであるということである最も重要なのだと思います。コード表のほとんどは、実質的に資源があることを自動的に生成されています。プロセスは、テーブルにいくつかのリソースを使用するときには、この動的ライブラリを直接ロードすることができます。コードのも動的ローディングは、フレーム層に書き込むことができ、デフォルトでは、リソース・テーブルをロードするすべてのプロセスです。あなたはリソーステーブルを使用する場合（たとえば、シーンのプロセスとしてgamesvr以外のプロセスに加えて、）他のプロセスでは、我々は非常に面倒である前に：どのリソーステーブルに使用するように指定したファイルの定義にあるように、とのリソーステーブルの場合そこに相互依存関係がありますが、これも来るように設定されているリソーステーブルに依存する必要があります。今、私たちはすべてのすべてのプロセスのためのリソーステーブルをロードすることができ、およびメモリの成長のリスクを心配する必要はありません。
第二に、あなたは推定資源テーブル値のメモリ制限を経験する必要はありません。機器と1000人の以上の学生を計画する際に例えば、機器構成を維持する長さ1000の配列の定義は、手動でメモリを必要とするリソーステーブルは、共有メモリを置くことです前からこの経験を（、変更するコードを変更する必要があります事前に割り当てられました）。リソーステーブルが静的に構築されているので、アレイのサイズは、完全に自動コード生成を行うことができます。また、我々はすべて自動的にツールによって生成され、自分の手書きインデックスコードは必要ありません。例えば、今だけ、あなたは自動的にコードにこれらのインデックスを生成することができ、ガイドにプライマリキーテーブルを指定する必要がニーズやレベルIDの問い合わせに応じて構成テーブルのスキルがあるかもしれません。
静的ビルドデータ構造は、もう一つの利点は、店舗により最適なメモリ構造を使用することが理論的に可能です。一般的には、リソース・テーブル・メモリは、このシナリオのために、我々はインデックスを行うには、より速く安くメモリデータ構造をバイHaxiテーブルを設計することができ、変更後に再ロードされることはありません。一例として、各主キー生成されるハッシュ関数の完全なハッシュを競合していない極小。動的な拡張したがってスパース（缶コンパクト配列）を格納するハッシュテーブルを使用する必要がないからです。基本的な考え方は、生成されたコードに押されても、コンパイルし、実行して算出、またはプッシュすることです。
、リロードプロセスは非常に単純であるができ、新しい動的ライブラリをロードするために、古い動的ライブラリをアンインストールします。リソーステーブル以来、それが必要とされる前に、新たなコンテンツのためのいくつかのメモリ空間を確保しないように、共有メモリを保持し、共有メモリの互換性の問題の構造を検討する必要はありません。
最後の点は、達成することは非常に簡単です。すべてのように静的なコード生成ツールを使用してPythonで書かれたコード、およびC ++資源テーブル管理コードとを含む、コード未満の1000行まで追加。
実装プロセスでも、程度のレコードと一緒に、あまりにも、ここでは、いくつかの興味深い質問に遭遇しました。
（1）一つには、Linuxの動的ライブラリのみの.text共有メモリセグメントです。そして、我々はそれを行う方法を、メインデータを共有するためにここにいますか？理解するための最初のものは、これは、データの一部がロードされるの過程で（構造的な書き込み可能なデータだけでなく、再配置テーブルなどを含む）を変更することがあるため、動的ライブラリは、メモリ・セグメントの.dataセクションを共有していない理由は、それがすべてのでなければならないということですプロセスがプライベートメモリを保持します。しかし、我々は、データの修正を持っていないので、メモリを共有することができます。解決策は単純である：使用CONSTアレイは、リソーステーブルを変更するために使用することができます。このメモリは.rodataの中に置かれるそう。そして、リンク段階では、リンカはセクションを.textのために、すべての.rodataのをマージします。
readelfが-lコマンド・プログラム・ヘッダを介してPSチェックELFファイルは.dataセクションに組み込まれるの.textセグメントに組み込まれている節を参照することができるであろう
（2）また、どのように熱い動的ライブラリのアップデートについての質問があります。私はいつもライブラリディレクトリを置き換えるために、直接ファイルについて考え前に（参照カウントをファイルに起因する）問題ではありません。しかし、上司は実際に新しいファイルの内容に新しいディレクトリエントリ・ポイントを作成し、その後、ディレクトリ内の元のディレクトリエントリを削除するには同等ではない、元の文書の内容を変更するcpコマンドを使用して、Linuxでカバーされ、指摘しました。原理が覆われている場合には、CPは（詳細を見ることができる新しいiノードを作成しないで、元のファイルのinodeを変更しますここ）。しかし、ここで私はより多くのバグのcpコマンドのように感じる：あなたは新しいiノードを作成するのではなく、書くときに似た、元のinodeを（書き換えを検討する必要がある場合はコピー処理は、元のファイルへの参照があるかどうかを検討すべきである場合にはコピー）。しかし、問題は、他の懸念があり、さらに綿密な表情を感じることがありますか？