私はバグを回避するためのいくつかのアプローチを見てきました。そして、速度のために何が機能するかを確認するためにいくつかのタイミングテストを実行しました ( http://jsfiddle.net/5dwwy/ )
アプローチ:
- 直接割り当て
このアプローチでは、剃刀の構文が変数に直接割り当てられます。これがエラーをスローするものです。ベースラインとして、JavaScript 速度テストは単純に数値を変数に直接代入します。
- Number コンストラクターを通過する
このアプローチでは、`Number(@ViewBag.Value)` のように、`Number` コンストラクターへの呼び出しで剃刀構文をラップします。
- ParseInt
このアプローチでは、かみそりの構文を引用符で囲み、「parseInt」関数に渡します。
- 値を返す関数
このアプローチでは、単にレーザー構文をパラメーターとして受け取り、それを返す関数が作成されます。
- 型チェック機能
このアプローチでは、関数はいくつかの基本的な型チェック (基本的には null を探します) を実行し、null でない場合は値を返します。
手順:
上記の各アプローチを使用して、afor-loop
は各関数呼び出しを 10M 回繰り返し、ループ全体の合計時間を取得します。次に、その for ループを 30 回繰り返して、10M アクションあたりの平均時間を取得します。次に、これらの時間を相互に比較して、どのアクションが他のアクションよりも速かったかを判断しました。
JavaScript が実行されているため、他の人が受け取る実際の数値は異なることに注意してください。ただし、重要なのは実際の数値ではなく、数値が他の数値とどのように比較されるかです。
結果:
直接割り当てアプローチを使用すると、1,000 万件の割り当てを処理する平均時間は 98.033 ミリ秒でした。コンストラクターを使用すると、Number
10M あたり 1554.93ms が得られました。同様に、parseInt
メソッドには 1404.27ms かかりました。2 つの関数呼び出しは、単純な関数で 97.5 ミリ秒、より複雑な関数で 101.4 ミリ秒かかりました。
結論:
理解するのに最もわかりやすいコードは、直接代入です。ただし、Visual Studio のバグのため、これはエラーを報告し、Intellisense で問題を引き起こし、漠然と間違っているという感覚を与える可能性があります。
最速のコードは単純な関数呼び出しでしたが、わずかな差でした。これ以上の分析は行っていないため、この差に統計的有意性があるかどうかはわかりません。型チェック関数も非常に高速で、直接割り当てよりもわずかに遅く、変数が null である可能性が含まれています。ただし、パラメーターが未定義の場合 (かみそり構文では null)、基本的な関数でさえ未定義を返すため、実際には実用的ではありません。
Razor 値を int として解析し、コンストラクターを介して実行すると、直接割り当てよりも 15 倍遅くなり、非常に遅くなりました。ほとんどの場合、Number
コンストラクターは実際には内部で を呼び出しています。parseInt
これにより、単純な よりも時間がかかる理由が説明されますparseInt
。ただし、外部で定義された (つまり、ファイルまたはアプリケーションの別の場所で) 関数を実行する必要がなく、Number
コンストラクターが整数から文字列への目に見えるキャストを実際に最小限に抑えることで、より意味のあるものになるという利点があります。
要するに、これらの数値は 1,000 万回の反復を実行して生成されたものです。単体での速度は計り知れないほど小さい。ほとんどの場合、コンストラクターを介して単純に実行することNumber
は、最も遅いにもかかわらず、最も読みやすいコードになる可能性があります。