私はゲームをしており、状態に名前を付けます。状態を扱う各更新では、名前、文字列を操作します。文字列を列挙型の値に置き換える価値があるのかどうか疑問に思っていましたか?文字列の代わりに列挙型スピードアップを使用していますか?
たぶん、ダムに聞こえるかもしれませんが、多くの状態があり、毎秒少なくとも30回処理されます。
おかげ
私はゲームをしており、状態に名前を付けます。状態を扱う各更新では、名前、文字列を操作します。文字列を列挙型の値に置き換える価値があるのかどうか疑問に思っていましたか?文字列の代わりに列挙型スピードアップを使用していますか?
たぶん、ダムに聞こえるかもしれませんが、多くの状態があり、毎秒少なくとも30回処理されます。
おかげ
さて、あなたは、パフォーマンスの問題を持っていますか?
確かに整数値を使用する方が高速ですが、実装されていれば十分速く、他の場所で時間を費やします。コメントに自分自身を残すかもしれない。
デフォルトでは、enumは内部的にはint
と扱われますので、何度もチェックするとより速くなります。しかし、1秒間に30回しかチェックされていない場合、このコストは他の推定コストに比べて無意味です。あなたは何が最も遅いかを見るためにプロファイリングしましたか?
[Not quite](http://msdn.microsoft.com/en-us/library/sbbt4032.aspx):_列挙型の承認された型は、byte、sbyte、short、ushort、int、uint、long、またはulongです._ –
あなたのリンクから: "列挙型要素のデフォルトの基本型はintです。"明示的に他のストレージクラスを使用する必要があります –
これは最初の文章ではありません。 –
私は個人的には、おそらく最大の、おそらく不必要な効率を考えると、ビットフラグを考慮する必要があります。これにより、標準のビット演算子を実行できます。
[Flags]
enum Choices
{
OptionOne = 0x0,
OptionTwo = 0x1
}
class MyClass
{
Choices mychoice = Choices.OptionOne | Choices.OptionTwo;
}
列挙型は、このインスタンスでは確かにきれいで、より優れた保守性を提供する...あなたはそのように状況をタイプミスするつもりはない(またはあなたがかもしれませんが、コンパイラはあなたを教えてくれます)。また、文字列の比較に比べて単純な整数比較を行う方が高速になります。
コーディングがすでに完了していて、このステータスの実装に固有のパフォーマンス上の問題がない場合、それを変更する理由はあまりありません。他の人が言っているように、それがあなたの唯一の問題ならばそれをプロファイルします。
アプリをプロファイリングしましたか?これは本当の問題なのか、ちょうど感知された問題なのでしょうか?インツは文字列より高速ですが、ボトルネックがあるかどうかをアプリで確認しています。フォローアップとして、より良い/より速いものが何かを行うときに文字列の比較を避けます。 – itsmatt