c - Ruby C 拡張機能と #system 経由の実行可能ファイルのスポーン

Question

C アプリケーションと対話する Ruby コードがいくつかあります。現在、アプリケーションにデータを渡す必要があるたびに、 Kernel#systemメソッドを使用して実行可能ファイルを生成します。Ruby C 拡張機能を作成する場合と比較して、このアプローチのシステム側の利点/欠点は何ですか。

Answer 1

カーネル#システム

利点

ネイティブ コードの呼び出しKernel#systemは、実装が最も簡単なオプションであり、したがってコーディングも最速です。柔軟性もあります。C コードだけでなく、シェル スクリプトや Python など、他の言語の実行可能ファイルも簡単に呼び出すことができます。

短所

を使用systemすると、比較的大量のオーバーヘッドが発生します。Ruby インタープリター プロセスをフォークし、サブシェルを実行し、C アプリケーションを呼び出して、子プロセスが終了するのを待ちます。これらはすべて、特にタイトなループで実行している場合、時間とシステム リソースの点でかなりコストがかかります。

C 拡張機能

利点

C 拡張機能を作成してネイティブ コードとやり取りすると、驚異的な速度と低いオーバーヘッドが得られます。また、C ランドとの間でデータを送受信する際の柔軟性が大幅に向上します。ではsystem、コマンドライン引数を介して子アプリケーションの入力をシリアル化できる必要があります (また、出力を収集するためにバッククォートまたはパイプを使用する必要があります)。ただし、拡張機能を作成する場合は、Ruby オブジェクトを および に渡すだけで済みます。 out、より自然な API を構築できます。

短所

C 拡張機能を適切に作成、ビルド、および配布するには、さらに多くの作業が必要です。また、C ランドで失敗すると、例外をスローする代わりにインタープリターをクラッシュさせることが多く、デバッグが難しくなります。注意しないと、書いているプラ​​ットフォームに縛られる可能性も高くなり、移植性が損なわれます。

概要

実際、最良のガイダンスは、単純なものから始めて、実際に測定可能なほど有益な C 拡張機能の複雑さを追加することです (参照: ベンチマーク後)。