编译还是解释？

标签：style   blog   http   tar   ext   color   

编译还是解释？

我们可能要问，什么时候应该用编译，什么时候应该用解释呢？最终的结果是几乎相同，因此，答案通常最终归结为生成代码的原始速度，虽然内存使用情况和启动时间也是主要的关注。如果需要代码执行得更快，那么编译通常是更好的结果，有一定的优势。

清单 12-8 的测试工具，能够重复执行 interpret 函数中的 createDynamicMethod 方法，计算出花费的时间；还测试在动态方法上的重要变化。这还生成一个新的 .NET 委托值，作为该句柄，调用生成的代码。可以看出，这是到目前为止最快的技术。记住，评估抽象语法树花费的时间，可以是直接地，也可以是以编译形式，没有测量出解析时间或编译时间。

清单 12-8 比较性能的测试工具

open System

open System.Diagnostics

openStrangelights.Expression

//expression to process

let e = Multi(Val 2.,Plus(Val 2., Val 2.))

//collect the inputs

printf"Interpret/Compile/CompileThrough Delegate [i/c/cd]: "

let interpertFlag = Console.ReadLine()

printf"reps: "

let reps = int(Console.ReadLine())

type Df0 = delegate ofunit -> float

type Df1 = delegate offloat -> float

type Df2 = delegate offloat * float -> float

type Df3 = delegate offloat * float * float -> float

type Df4 = delegate offloat * float * float * float -> float

//run the tests

match interpertFlag with

| "i" ->

  let args = Interpret.getVariableValues e

  let clock = new Stopwatch()

  clock.Start()

  for i = 1 to reps do

    Interpret.interpret e args |> ignore

  clock.Stop()

  printf "%i" clock.ElapsedTicks

| "c" ->

  let paramNames = Compile.getParamList e

  let dm = Compile.createDynamicMethod e paramNames

  let args = Compile.collectArgs paramNames

  let clock = new Stopwatch()

  clock.Start()

  for i = 1 to reps do

    dm.Invoke(null, args) |> ignore

  clock.Stop()

  printf "%i" clock.ElapsedTicks

| "cd" ->

  let paramNames = Compile.getParamList e

  let dm = Compile.createDynamicMethod e paramNames

  let args = Compile.collectArgs paramNames

  let args = args |> Array.map (fun f -> f :?> float)

  let d =

    match args.Length with

    | 0 ->dm.CreateDelegate(typeof<Df0>)

    | 1 ->dm.CreateDelegate(typeof<Df1>)

    | 2 ->dm.CreateDelegate(typeof<Df2>)

    | 3 ->dm.CreateDelegate(typeof<Df3>)

    | 4 ->dm.CreateDelegate(typeof<Df4>)

    | _ -> failwith "too manyparameters"

  let clock = new Stopwatch()

  clock.Start()

  for i = 1 to reps do

    match d with

    | :? Df0 as d -> d.Invoke() |>ignore

    | :? Df1 as d -> d.Invoke(args.[0])|> ignore

    | :? Df2 as d -> d.Invoke(args.[0],args.[1]) |> ignore

    | :? Df3 as d -> d.Invoke(args.[0],args.[1], args.[2]) |> ignore

    | :? Df4 as d -> d.Invoke(args.[0],args.[1], args.[2], args.[4]) |> ignore

    | _ -> failwith "too manyparameters"

  clock.Stop()

  printf "%i" clock.ElapsedTicks

| _ -> failwith "not anoption"

表 12-2 汇总了执行程序计算表达式 Multi(Val2.,Plus(Val 2., Val 2.)) 的结果。

表 12-2汇总处理表达式 Multi(Val 2.,Plus(Val 2., Val 2.))，重复不同的次数（每微秒次数）

从表12-2 和图12-2 中可以看出，编译和通过委托编译在重复次数少时更快。但是，注意，重复1、10 和 100 次，需要的时间增长不明显，这是因为重复数量小，每次重复花费的时间不明显；真正花费的时间是即时编译器（JIT）用来把中间语言代码编译成本地代码，这是相对显著的。这就是为什么编译和通过委托编译的时间很接近，它们即时编译的代码数量相似；而解释花费更长的时间，是因为必须即时编译更多的代码，特别是解释器。但是，即时编译是一次性成本，每个方法只需要即时编译一次，因此，随着重复次数的增加，一次性的成本已经支付，这才真正看到相对性能成本的图像。

图 12-2 评估表达式1 + 1 的时间花费随计算次数的变化

[

图与程序已经不配套了，图还是原来的版本，程序是新的

]

从图12-2 可以看得更清楚，随着重复数量的增加，编译的成本急剧上升。这是因为，访问编译过的 DynamicMethod 方法通过调用Invoke，这是很昂贵的，每重复一次就增加一次成本，因此，用于编译的方法的耗时与重复的次数成正比。然而，问题在于不使用编译，而在于如何调用编译的代码。事实证明，通过委托调用 DynamicMethod，而不是在动态委托上的Invoke 成员，能够一次性的绑定方法的成本，因此，在打算多次评估表达式时，执行DynamicMethod，这种方法更有效。从这些结果来看，通过委托编译请求在速度方面最好的。

这个分析还表明测量的重要性，不要认为编译一定能筛期望的性能收益，除非真的看到针对具体数据集的好处，使用所有可用的技术来确保代码中没有不必要的躲藏开销。然而，现实中还会有其他许多因素，例如，如果表达式经常改变，解释器会要求再次即时编译一次。每次编译表达式将需要即时编译，因此，如果想看到任何性能提升，需要多次运行编译的代码。鉴于解释代码通常更容易实现，编译码仅在某些特定情况下才提供了显著的性能提升，因此，解释通常是一种更好的选择。

当处理的情况是需要尽可能快地执行代码，通常最好的方法是尝试不同的几个方法，然后，分析应用程序，看哪一种方法获得更好的结果。有关性能分析的更多内容，请看第十二章。

[

最后这一句话可能已经远处着落了。

本章就是第十二章。

原来的第十二章是“工具套件、NET 编程工具”，在新版本中好像没有了。

]

第十二章小结

在这一章，我们学习了 F# 中面向语言编程的主要特点与技术。可以看到有不同的技术，有使用数据结构作为小语言，或者使用引用，都涉及到对现有 F# 语法的改变或扩展；其他的，比如实现解析器，可以处理任何基于文本的语言，不管这种语言是自己设计的，或者，更常见的是已有的语言。所有这些技术，如能正确使用，都能极大地提高生产力。

下一章，我们将看一下如何使用 F# 解析文本，可以用它来创建不需要嵌入在 F# 的语言，也可以处理定义好的主要文本格式。

编译还是解释？,布布扣,bubuko.com

编译还是解释？

标签：style   blog   http   tar   ext   color   

原文地址：http://blog.csdn.net/hadstj/article/details/29576727