Date.now()获胜。请参见jsPerf test。
但正如上面的评论所指出的，与您将要做的任何其他事情相比，CPU成本可能都是无趣的。
@techfoobar提到了分配Date对象的成本（或者，实际上，* 垃圾收集 * 这些Date对象的成本）。这可能是也可能不是一个重大的胜利，因为Date.now()可能是分配号码，这将是昂贵的。

此外，如果时间戳是为了给数据加时间戳以外的任何事情而获得的，例如代码执行的时间，那么最好考虑是否可以通过setInterval或setInterval调用来实现，而不直接访问时间戳值。

由于这里没有讨论performance.now（），并且由于 jsperf.com现在似乎已经关闭，我做了一些简单的测试，结果表明，快速性的排名是：

1. Date.now（）--大约1秒，1000万次迭代
2. new Date（）--大约2秒，1000万次迭代
3. performance.now（）--大约4秒，1000万次迭代
   遗憾的是，performance.now（）比Date.now（）慢4倍。这是在Chrome上。
   这是我的代码，升级到1亿次迭代，performance.new（）测试变得更糟。不要担心我使用performance.now（）作为所有3个选项的测量计时器，重要的是循环中的内容。我在上一次测试中进行了1亿次迭代，因为我想看看new Date（）和www.example.com（）上的垃圾收集是否Date.now会启动并惩罚我们。但不是，更糟糕的不是它们，而是performance.now（）方法。

function perftest(iterations, fn) {
    const start = performance.now();
    for(let i = 0; i < iterations; i++)
        fn();
    return performance.now() - start;
}

> perftest(100000000, () => Date.now())
< 11285.5
> perftest(100000000, () => new Date())
< 22834.59999999404
> perftest(100000000, () => performance.now())
< 48602.40000000596

顺便说一下，通过fn（）函数调用的间接性非常非常小。与直接在循环中调用测试语句相比，它增加了大约200 ms的总时间。