Timer：

在前端开发中，我们经常会使用setTimeout 函数组，这组函数其实不属于语言标准，他们只是extentsion ，在浏览器中，他们属于 BOM（浏览器对象扩展），即它的确切定义为：window.setTimeout ,和window.alert , window.open 等函数处于同一层次。

http://code.google.com/p/doctype/wiki/WindowSetTimeoutMethod

你可以在浏览器的控制台监测window 对象，或查看chromium 的实现 :
http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/page/DOMWindow.h

在nodejs ，当然也要实现自己的Timer ，在nodejs 的src 目录下，timer.h/cc 是对 libev 中的 ev_timer 进行了一层浅包装，在src/node.js 文件中，把这组函数放置于全局范围中（相当于浏览器中window）

startup.globalTimeouts = function() {

  global.setTimeout = function() {

    var t = NativeModule.require('timers');

    return t.setTimeout.apply(this, arguments);

  };

  global.setInterval = function() {

    var t = NativeModule.require('timers');

    return t.setInterval.apply(this, arguments);

  };

...

通过我们对libev的分析，我们已经知道，在libev中队timer的添加/删除/更新操作都是 O(lg(n)) ,
（libev 分析 http://cnodejs.org/blog/?p=2489）

但其实在我们的日常开发中，以网络套接字为例，我们往往会对其设置timeout，即如果一段时间（120s 或 60s）此套接字没有活动事件发生，我们就关闭它（这种技巧非常重要，否则由于一些内部或外部的原因，很容易出现描述符占用过多的现象），注意到，我们的超时时间是一个统一的值，这时候，我们可以采用如下算法：(lib/_linklist.js 真实实现)

当我们在不同的时刻多次调用 setTimeout(fn ,1000) 时，我们把所有的这些事件仅由一个timer 来管理，这些事件被放到一个双向链表中，其顺序自然而然的就是按时间来排序的，当某一时刻，timer 触发时，会依次的从prev链表头中取出节点，进行检查，如果超时则触发...
（参见lib/timer_legacy.js 由于libev无法在windows上很好的工作，所以nodejs项目组又对libev，libeio 作了一层封装，称为libuv, 使用了传统的方法文件以_legacy 结尾，使用了libuv 的以_uv 结尾，如net_legacy.js ,net_uv.js ,timers_legacy.js ,timers_uv.js 等,）

当我们需要更改某异步事件时，比如，我们添加超时控制的socket上发生了read/ write 事件，这时候，我们需要重新reset 计时，我们仅需要把这个事件从链表中转移到链表尾部即可
(参见 lib/net_legacy.js)

删除时的情况与此类似，所以在此场景下，仅耗费一个ev_timer ，而我们的所有异步事件的添加/删除/更新都是 O(1) 复杂度.

注意，在lib/timer_*.js 中，当超时值<= 0 时是不做优化的,

exports.exports.setTimeout = function(callback, after) {

  if (after <= 0) {

    // Use the slow case for after == 0

   timer = new Timer();

   timer.ontimeout = callback;

  else{

    ...

  }

同时setInterval 函数也是没做优化的.

nextTick :

nextTick是个很有意思的东西，它其实是一个prepare watcher 来实现的，在libev中的event loop 的每次迭代，在nodejs 中就叫做 “Tick” ，而在libev 中，支持prepare watcher ，它在每次迭代开始时触发，在src/node.cc 中我们看到类似代码（v4.9为例）：

ev_prepare_init(&node::prepare_tick_watcher, node::PrepareTick);

ev_prepare_start(EV_DEFAULT_UC_ &node::prepare_tick_watcher);

ev_unref(EV_DEFAULT_UC);

在函数 PrepareTick 中会调用一个回调函数，此函数 _tickCallback 在 src/node.js 中：

startup.processNextTick =function() {

  var nextTickQueue = [];

  process._tickCallback = function() {

  ...

  }

  process.nextTick = function(callback) {

    nextTickQueue.push(callback);

    process._needTickCallback();

   };

};

当我们调用API process.nextTick 时，其实就是向nextTickQueue 这个闭包队列中添加一个函数，当下次事件循环开始时，会自动触发prepare_tick_watcher ,调用我们设定的函数。
注意，上面有个问题，那就是如果没有机会进行下次事件循环，比如，此时没有实质性的watcher可供监测了，这时事件循环就会退出，为了避免着这种情况, nextTick 函数中会调用一次 process._needTickCallback() ,这个函数会使tick_spinner （一个idle watcher）处于活跃状态 , 来防止事件循环的退出。

由nextTick 原理我们可知，当我们添加一个待处理事件时，其复杂度为O(1) ,但如果你用setTimeout(fn ,0) 的话，如我们在libev分析中所讲，其一进一出均为 O(lg(n)) , 所以nodejs官方文档讲：

On the next loop around the event loop call this callback. This is not a simple alias to setTimeout(fn, 0), it's much more efficient.

nextTick 确实高效的多，诚不我欺也!

小节：
通过以上分析，我们至少得出2条粗浅的结论：
#1 如果可能的话，调用setTimeout时，尽量使用相同的超时值
#2 尽量用process.nextTick 来代替 setTimeout(fn ,0)