実装が C++ である新しい TCL コマンドを定義しています。コマンドはデータ ストリームを照会するもので、構文は次のようなものです。
mycmd <arg1> <arg2> ...
アイデアは、このコマンドが引数のリストを取り、各引数に対応するデータを持つリストを返すということです。
私の同僚は、単一の引数を使用するのが最善であり、複数の値が必要な場合は、コマンドを複数回呼び出すだけでよいとコメントしました。
他にもいくつかの議論がありますが、お互いに同意できないのはパフォーマンスです。
複数の引数が必要な場合、TCLインタープリターを通過するのは1回のコストであるため、私のバージョンの引数のリストはより高速である必要があると思います。
彼のコメントは私には新しい -
- 関数の実装はキャッシュされます
- TCL関数へのアクセスは、TCLデータへのアクセスよりも高速です
この推論は正しいですか？
コマンドを呼び出すために使用する場合Tcl_EvalObjv、Tcl インタープリターを経由しません。コストは 1 回のハッシュ テーブル ルックアップ (コマンド名を含む を再利用する場合はそれ以下Tcl_Obj*) であり、コマンドの実装になります。それ以外の場合、リストを作成Tcl_Obj*して(たとえば、 を使用してTcl_NewListObj) 呼び出しTcl_EvalObjても、リスト作成コードは置換のないコマンドでもあるリストを生成することが保証されているため、特殊なケースであるため、ほぼ同じくらい安価です。通常の文字列を作成してTcl_Eval(またはTcl_EvalObj) に渡すと、解析する必要があるため、大幅に遅くなります。(OTOH、同じもの Tcl_Obj*をTcl_EvalObj複数回続けて渡すと、内部でバイトコードにコンパイルされるため、高速になります。)
値へのアクセス (つまり、参照へのアクセス) は、それらの値の内部表現がアクセス関数が必要とする型と一致していれTcl_Obj*ば、非常に高速です。不一致がある場合、内部型変換関数が呼び出される可能性があり、多くの場合、それらは比較的高価です。内部表現を理解するために、次のことを考慮してください。
string— Unicode 文字の配列integer— C long(任意精度の作業にスピルオーバーする場合を除く)listTcl_Obj*—参照の配列dict— にマップTcl_Obj*するハッシュ テーブルTcl_Obj*script— バイトコード版command— 実装関数へのポインタOK、これらは正確なタイプではありません (多くの場合、他の簿記データもあります) が、モデルとして考えるべきものです。
「どれが最速か」に関しては、質問に答える唯一の正気の方法は、それを試してみて、どれが実際に最速かを確認することです。答えは、実際のコードを持っていない人が予測するにはあまりにも多くの要因に依存します。Tcl から呼び出している場合、このtimeコマンドはこの種のパフォーマンス分析作業に最適です (これが目的で設計されています)。C または C++ から呼び出している場合は、その言語のパフォーマンス測定イディオムを使用します (私にはわかりませんが、Stack Overflow を検索します)。
自分自身？API をできるだけ明確かつ簡潔に記述することをお勧めします。実際の操作を説明し、余分な 0.01% のパフォーマンスを絞り出そうとするためにすべてを歪曲しないでください。