NWMatcher — Javascript CSS 选择器和匹配器，由 Diego Perini编写— 使用Function构造函数（1、2、3、4等）创建（“编译”）选择器匹配器的高效版本。

该基准测试（我只是跑在Chrome 5）不言自明：

注意 NWMatcher 和 Sizzle 的区别，这是一个非常相似的选择器引擎，只是没有函数编译:)

附带说明一下，ECMAScript 5不会在调用Function. 既不是严格模式，也不是“标准”模式。然而，严格模式对诸如“eval”和“arguments”之类的标识符的存在引入了一些限制：

• 你不能用这样的名字来声明变量/函数/参数：

  function eval() { }
  var eval = { };
  function f(eval) { } 
  var o = { set f(eval){ } };
  

• 您不能分配给这样的标识符：

  eval = { };
  

另请注意，在严格模式下，eval语义与 ES3 中的语义略有不同。严格模式代码不能在调用它的环境中实例化变量或函数：

 eval(' "use strict"; var x = 1; ');
 typeof x; // "undefined"

当 JSON 解析器对象不可用时，jQuery 使用它来解析 JSON 字符串。对我来说似乎是合法的:)

        // Try to use the native JSON parser first
        return window.JSON && window.JSON.parse ?
            window.JSON.parse( data ) :
            (new Function("return " + data))();

我new Function()在我正在开发的 Web 应用程序之一中使用构造函数作为内嵌 JS 解释器：

function interpret(s) {
  //eval(s); <-- even worse practice
  try {
      var f = new Function(s);
      f();
    }
  catch (err) {
      //graceful error handling in the case of malformed code
  }
}

当我通过 AJAX（不是iframe）流式传输内容时，我一直interpret()在readyStateChange == 3. 这出奇的好。

编辑：这是一个明确的案例研究，表明它new Function()绝对比eval(). 即你永远不应该（很少？）使用 eval 代替new Function().

http://polyfx.com/stuff/bsort.html <- 1000 次迭代版本，可能会导致浏览器崩溃

http://polyfx.com/stuff/bsort10.html <- 较短的版本

EVAL是平均几乎8倍慢new Function()。

John Resig 使用 Function 构造函数来创建用 asp 语法编写的客户端模板的“编译”版本。 http://ejohn.org/blog/javascript-micro-templating/

这是与我的其他答案不同的案例。

不久前，我使用 Function 构造函数来创建重复调用的自定义字符串格式化程序。创建函数的开销（我认为这是您正在谈论的性能问题）远远超过自定义函数的改进性能，这些函数是在运行时创建的，专门用于处理特定的格式字符串，因此不需要评估大量不相关的情况——或者解析格式字符串，就此而言。我想这有点像编译正则表达式。