各値が、、またはDataTableを実際に表すことができる に文字列として格納された値があります(これらはすべて、外部データ ソースからのインポート プロセス中に文字列に変換されました)。各値が実際にどのような型であるかをテストして確認する必要があります。intdoublestring
アプリケーションにとってより効率的なのはどれですか (または実際的な違いはありませんか)?
int(そして)に変換してみてくださいdouble。変換が機能する場合は、true. 例外がスローされた場合は、 を返しfalseます。intorのパターンに一致するように設計された正規表現doubledouble.TryParse を使用すると、パフォーマンスが向上します。
最適化をオンにしてコンパイルするかどうかに応じて、メソッドごとに異なる結果が得られます。基本的にいくつかのオプションがあります。
object o;
//checking with is
o is int
//check type
o.GetType() != typeof( int )
//cast and catch exception
try{ int j = (int) o; }
catch {}
//use the tryparse
int.TryParse( Convert.ToString( o ), out j )
これらの10,000回のそれぞれを試行し、それぞれの期間を返すコンソールアプリを簡単に設定できます（oがintの場合と、それ以外の場合のテスト）。
このtry-catchメソッドは、オブジェクトがintを保持している場合は最も速く、保持していない場合ははるかに遅くなります（よりも遅くなりますGetType）。 int.TryParse文字列がある場合はかなり高速ですが、不明なオブジェクトがある場合は遅くなります。
興味深いことに、.Net 3.5と最適化をオンにすると、oが実際にintである場合o is intと同じ時間がチェックにかかります。oが実際に何か他のものである場合、わずかに遅くなります。try-catcho is int
迷惑なことに、次のようなことを行うと、FxCopは警告をスローします。
if( o is int )
int j = (int) o;
しかし、これはFxCopのバグだと思います。intが値型であることがわからないため、o as int代わりに使用することをお勧めします。
入力が常に文字列である場合は文字列int.TryParseが最適です。そうでない場合は、is演算子が最も速くなります。
文字列があるので、それがdoubleではなくintであることを知る必要があるかどうかを調べます。int.TryParse合格した場合はdouble.TryParse、チェックの数を半分にすることができます。intを期待する場合は、doubleまたはstringのいずれかを返し、doubleをフロアします。
そのようなマイクロパフォーマンスについては、あまり心配しないでください。何かを機能させるだけで、可能な限り明確かつ簡潔で読みやすいものにする方がはるかに優れています。あなたができる最悪のことは、わずかなパフォーマンスのために可読性を犠牲にすることです.
結局のところ、パフォーマンスの問題に対処する最善の方法は、実際のパフォーマンスの問題があることを示すデータがある場合に備えてそれらを保存することです...そうしないと、マイクロ最適化に多くの時間を費やし、実際にはメンテナンスコストが高くなります後で。
この解析状況が実際にアプリケーションのボトルネックであることがわかった場合は、問題を解決するための最速の方法を試してみてください。Jeff (および他の多くの) は、この種のことについて多くのブログを書いていると思います。
問題は、答えが 3 つのタイプすべてになる可能性があることです。
3 は、int、double、または文字列の可能性があります!
それは、あなたが何をしようとしているのか、そしてそれらが特定のタイプであることがどれほど重要であるかによって異なります. できる限りそのままにしておくか、代わりに、それぞれをマークする方法をいくつか用意するのが最善かもしれません（元の文字列のソースを制御できる場合）。
個人的には int.tryparse、次に double.tryparse を使用します。これらのメソッドのパフォーマンスは非常に高速です。どちらもブール値を返します。両方とも失敗した場合は、データの定義方法に従って文字列が作成されます。