我已经看到了几种解决该错误的方法,并且我运行了一些计时测试以查看什么对速度有效(http://jsfiddle.net/5dwwy/)
方法:
- 直接赋值
在这种方法中,剃刀语法直接分配给变量。这就是引发错误的原因。作为基线,JavaScript 速度测试只是将数字直接分配给变量。
- 通过 `Number` 构造函数
在这种方法中,我们将 razor 语法包装在对“Number”构造函数的调用中,就像在“Number(@ViewBag.Value)”中一样。
- 解析整数
在这种方法中,剃刀语法放在引号内并传递给 `parseInt` 函数。
- 价值返回功能
在这种方法中,创建了一个函数,它简单地将剃刀语法作为参数并返回它。
- 类型检查功能
在这种方法中,该函数执行一些基本的类型检查(基本上是寻找 null),如果它不为 null,则返回该值。
程序:
使用上面提到的每种方法,afor-loop
重复每个函数调用 10M 次,得到整个循环的总时间。然后,该 for 循环重复 30 次以获得每 10M 动作的平均时间。然后将这些时间相互比较,以确定哪些动作比其他动作更快。
请注意,由于它是在运行 JavaScript,因此其他人收到的实际数字会有所不同,但重要性不在于实际数字,而是数字与其他数字的比较。
结果:
使用直接分配方法,处理 10M 分配的平均时间为 98.033 毫秒。使用Number
构造函数每 10M 产生 1554.93ms。同样,该parseInt
方法耗时 1404.27ms。两个函数调用对于简单函数花费了 97.5ms,对于更复杂的函数花费了 101.4ms。
结论:
要理解的最简洁的代码是直接赋值。但是,由于 Visual Studio 中的错误,这会报告错误,并可能导致 Intellisense 出现问题并给人一种模糊的错误感。
最快的代码是简单的函数调用,但只差一点点。由于我没有做进一步的分析,我不知道这种差异是否具有统计学意义。类型检查功能也非常快,仅比直接赋值稍慢,并且包括变量可能为空的可能性。但是,这并不实际,因为如果参数未定义(剃刀语法中的 null),即使是基本函数也会返回 undefined。
将 razor 值解析为 int 并通过构造函数运行它非常慢,比直接赋值慢 15 倍。很可能Number
构造函数实际上是在内部调用parseInt
,这可以解释为什么它比简单的parseInt
. 然而,它们确实具有更有意义的优点,不需要执行外部定义的(即文件或应用程序中的其他地方)函数,Number
构造函数实际上最小化了整数到字符串的可见转换。
最重要的是,这些数字是通过 10M 次迭代生成的。单品上,速度小得不可估量。对于大多数人来说,简单地通过Number
构造函数运行它可能是最易读的代码,尽管它是最慢的。