Hello Micro优化怪胎此处。两个类似的问题。
-
我有许多（400）var可以是字符串或空的，空的时要使用什么？空还是0？OK 0记住了一个int，但null是4个字符。>
-
在脚本中，我使用了许多布尔var，我想知道是否可以更好地使用true false或1 0，cos，又是4个chars。
我尝试自己基准测试，但我不能...这是测试代码：
1A：
<script> var t0, t1, l; var c = true;
t0 = performance.now();
var li = ["abcd1234",0,"abcd1234",0,"abcd1234",0]; //500 more of em.
l = li.length;
for (i = 0; i < l; i++) { if (li[i] !== 0 ) { c = true; } else { c = false; } }
t1 = performance.now();
console.log((t1 - t0) + " ms"); </script>
1b：
<script>var t0, t1, l; var c = true;
t0 = performance.now();
var li = ["abcd1234",null,"abcd1234",null,"abcd1234",null]; //500 more of em.
l = li.length;
for (i = 0; i < l; i++) { if (li[i] !== null ) { c = true; } else { c = false; } }
t1 = performance.now();
console.log((t1 - t0) + "ms"); </script>
2a：
<script>var t0, t1, l; var c = true;
t0 = performance.now();
var li = [true,false,true,false,true,false]; //500 more of em.
var l = li.length;
for (i = 0; i < l; i++) { if (li[i] === true ) { c = true; } else { c = false; } }
t1 = performance.now();
console.log((t1 - t0) + "ms"); </script>
2b：
<script> var t0, t1, l; var c = 1;
t0 = performance.now();
var li = [1,0,1,0,1,0]; //500 more of em.
var l = li.length;
for (i = 0; i < l; i++) { if (li[i] === 1 ) { c = 1; } else { c = 0; } }
t1 = performance.now();
console.log((t1 - t0) + "ms"); </script>
测试结果：每个数组800K vars，时间是5页加载的平均值。
1a：0 Time 11.99 ms |尺寸5.35 MB
1B：零时间1.78 ms |尺寸6.59 MB
2A：True False时间1.77 MS |尺寸4.53 MB
2B：1 0时间1.78 ms |尺寸1.64 MB
我必须说，在较小数量的var时，差异（时间和大小）较小。
从性能角度来看，0对CC_1的字符数量与null的字符数并不重要。他们唯一会影响的是文件大小，但是由于GZIP或其他Web压缩会在字典中放置重复单词，因此它们出现多次都没关系（如果您真的在乎性能，那么您肯定会使用GZIP或更好）。
微观优化很难出于两个原因：
-
错误的基准真的很容易。
-
我们优化的代码可能不是经常运行的代码。
-
在优化下载尺寸时，我们通常会忘记，在运输过程中的压缩可以比您更好地收缩代码。
-
我们可能正在编写运行的代码，而不是运行 LIST 的代码。。
不良基准：JS发动机变得更聪明。许多简单的基准不能复制现实世界的条件。口译员删除无副作用的代码；我帮助解决了这些错误。与具有数百kb脚本，标记和CSS的真实应用程序不同，整个测试可能适合处理器缓存。样本数据的排序可能不同，也可能具有较少的元素或行。
过早优化：我们查看我们的代码，并看到一个复杂的部分，该部分有很多条件，也许是一个嵌套的循环，然后想："必须有更好的方法。"但是，如果仅运行一次复杂的代码，或者仅在用户保存或游戏启动时仅运行一次，则可以修复它可能不会改善体验。
压缩：GZIP比您可能更好地找到代码的相同部分。在为库编写代码时，我有时会将其粘贴到Google Cloes Closure编译器服务中，以查看有关构建优化和压缩的统计信息。某些代码大小的优化实际上使结果更大，因为它会减少压缩。尝试将您的代码示例放入其中并查看其说什么。
- Google关闭编译器服务
运行较少的代码：查看代码，看看它是否需要首先工作：
- 结果对于输入是稳定的吗？它可以缓存还是回忆？
- 结果迅速被丢弃了吗？它可以节流或拒绝吗？
这些是我不考虑过早的优化。有时，即使没有减少您编写的代码量，您也可以收缩运行的代码。
只需写它：最好的计划通常是只编写您的代码。一旦您运行它，请将其配置为查看它花费最多的时间。也许您只需要优化一些功能或油门。
在我的角度上，如果要清除变量，最佳方法是定义'null'。无论如何，现代浏览器能够清除未使用的变量和垃圾收集器不会过度填充。
测试1：我要说的是，当没有值时，零是零。测试2：我仍然无法在详细时间告诉赢家，但是对于true false而言，尺寸为0和1。
我还不开心...