如手册中所述，http://www.erlang.org/erldoc?q=erlang:now
如果您不需要返回值是唯一且单调增加的，请使用os：timestamp / 0来避免一些开销。
os：timestamp / 0应该比erlang更快：now / 0
但我在我的电脑上测试了计时器：tc / 3，对于10000000个电话，以微秒为单位的时间是：
erlang：现在951000
os：时间戳1365000
为什么erlang：now / 0比os更快：timestamp / 0？
我的操作系统：Windows 7 x64，erlang版本：R16B01。
------------------编辑-----------------
我并行编写了另一个测试代码（100个线程），os：timestamp / 0并行执行得更好。这是数据：
----- single thread ------
erlang:now 95000
os:timestamp 147000
----- multi thread ------
erlang:now 333000
os:timestamp 91000
所以，我认为“开销”是并行的。
答案 0 :(得分：12)
我一直认为“一些开销”的评论是非常有趣的。 erlang:now/0实现其提供有保证的唯一，单调递增值的技巧的方法是取出每个VM的全局锁。在串行测试中，您不会注意到任何事情，但是当您运行大量并行代码时，您可能会这样做。
函数os:timestamp/0不会锁定，可能在两个进程中返回相同的值。
答案 1 :(得分：6)
这是recently discussed on the erlang-questions mailing list（“erlang：now（）vs os：timestamp（）”于2013年4月3日），其中出现了两个有趣的结果：
erlang:now似乎比解释代码中的os:timestamp更快（与编译代码相比，os:timestamp更快）。os:timestamp代替erlang:now来衡量所花费的时间，因为erlang:now会强制时钟前进。答案 2 :(得分：4)
除了麻烦的优秀答案之外，erlang:now()在串行测试中更快的原因可能是它避免了内核，因为你可能比时间进展更快地调用它然后你处于这样的情况：你不经常点击内核。
但是请注意，在添加多个核心之前，您的测试是欺骗性的。然后os:timestamp()像鳟鱼写的那样，会胜过erlang:now()。
另请注意，您处于弱势平台，即Windows。这通常会以非平凡的方式影响绩效。