一个无DOM，静态类型的，提前编译的javascipt代码与本机代码的性能比较如何？ [英] How would a DOM-less,statically typed, ahead-of-time-compiled javascipt code compare to native code performance-wise?

问题描述

传统的答案是为什么Javascript比本机代码慢？是：因为它是解释。这个说法的问题是，解释不是语言本身的质量。事实上，现在大多数Javascript代码是JIT的，但是，这甚至不接近原生速度。

The traditional answer to "why is Javascript slower than native code?" is: "Because it's interpreted". The problem with this claim is that interpretation is not a quality of the language itself. As a matter of fact, nowadays most Javascript code is being JITed, still, this isn't even close to native speed.

如果我们从方程并使Javascript AOT编译？然后它会匹配本机代码的性能吗？如果是，为什么这不是通过网络*？如果不是，现在的性能瓶颈在哪里？

What if we remove the interpretation factor from the equation and make Javascript AOT compiled? Will it then match the performance of native code? If yes, why isn't this widely done over the web*? If no, where is the performance bottleneck now?

如果新的瓶颈是DOM，如果我们消除了吗？将一个无DOM，编译的Javascript与本机代码一样高效？如果是，为什么这不是通过网络**广泛做？如果不是，现在的性能瓶颈在哪里？

If the new bottleneck is DOM, what if we eliminate that too? would a DOM-less, compiled Javascript be as efficient as native code? If yes, why isn't this widely done over the web**? If no, where is the performance bottleneck now?

在剥离DOM部分和解释部分后，我可以看到Javascript和C / C ++之间的唯一的巨大差异是事实上前者具有动态类型。假设我们消除这一点，最终得到一个无DOM，静态类型，提前编译的Javascipt。如何与本地代码比较？如果它会有效率，为什么不是这么广泛使用？如果不是，现在的瓶颈在哪里？在这种状态下，JavaScript几乎等同于C。

After stripping the DOM part and the interpretation part, the only big difference I can see between Javascript and C/C++ is the fact that the former has dynamic types. Suppose we eliminate that too and end up with a DOM-less,statically typed, ahead-of-time-compiled Javascipt. how would that compare to native code? If it would be as efficient, why isn't this widely used? If not, where is the bottleneck now? In this state, JavaScript is nearly identical to C.

*可能会说JIT加载速度更快，但这不会解释为什么AOT没有被使用对于资源密集型的网络应用程序，如3d视频游戏，其中AOT性能的好处是非常值得的初始AOT编译延迟。 （并且存在显着的游戏加载延迟）

*One might say that JIT is faster to load, but this wouldn't explain why AOT isn't being used for resource-intensive web apps such as 3d video games, where the AOT performance benefit is well worth the initial AOT compilation delay. (and a significant "game loading" delay is present anyways)

**无DOM的JavaScript将使用WebGL / Canvas来与用户交互。这目前需要最小的DOM，它定义了最初的HTML5画布，但是如果它的性能优势值得的话，这在理论上可以通过修改技术来消除。假设在回答时可以使用无DOM的WebGL / Canvas。

**a DOM-less javascript would use WebGL/Canvas to interface with the user. This currently requires minimal DOM, which defines the initial HTML5 Canvas, but this can theoretically be eliminated by revising the technology if it's worth the performance benefit. Assume that DOM-less WebGL/Canvas is possible when answering.

编辑：我说的是客户端编译。

I am talking about client-side compilation.

推荐答案

重要提示：

你似乎主张一个剥离的，静态类型的可编译版本的JS。显示的第一件事是，你不知道什么是JS：一个多范式编程语言，支持基于原型的OO，命令式和函数式编程 范例。关键是功能范例。除了Haskell，在定义了自己的中缀运算符之后，它可以是强类型的，一个功能语言不能是静态类型的AFAIK。想象一下类似C的函数定义返回闭包：

Important:
You seem to advocate a stripped, statically typed compilable version of JS. The first thing that shows is that you have no clue as to what JS is: a multi-paradigm programming language, that supports the Prototype-based OO, imperative and functional programming paradigms. The key being the functional paradigm. Apart from Haskell, which can be sort-of strong typed after you've defined your own infix operators, a functional language can't be statically-typed AFAIK. Imagine C-like function definitions that return closures:

function a = (function (Object g)
{
    char[] closureChar = g.location.href;
    Object foo = {};
    Function foo.bar = char* function()
    {//This is a right mess
        return &closureChar;
    };
}(this));

函数也是一个第一类对象。使用吨的lamda函数返回对象，引用函数可能会返回自己，其他函数，对象或原语...在地球上你会写这一切吗？ Js函数是创建范围，构造代码，控制程序的流程，因为它们是分配给变量的东西。

A function is a first class object, too. Using tons of lamda-functions that return objects, that reference functions that might return itself, other functions, objects or primitives... How on earth are you going to write all that? Js functions are as much a way of creating scopes, structuring your code, controlling the flow of your program as they are things that you assign to variables.

提前编译JS的问题很简单：编译代码，这将需要运行在如此庞大的数组不同平台：运行Windows，OSX，linux，UNIX以及平板电脑和智能手机的台式机/笔记本电脑及其不同的移动浏览器...
¥b $ b即使您已设法写入&编译JS，它在所有平台上运行，JS的速度仍然局限于单线程，并在JS引擎（如Java在VM上运行）上运行。

The problem with compiling JS ahead of time is quite simple: you compile code, that will have to run on such a vast array of different platforms: Desktops/laptops running Windows, OSX, linux, UNIX as well as tablets and smartphones with their different mobile browsers...
Even if you did manage to write & compile JS, that runs on all platforms, the speed of JS still is limited to it being single threaded, and running on a JS engine (like Java runs on a VM).

编译代码客户端已经完成。真的，需要一些时间，但不是一个可怕的很多。它是相当资源密集型，所以大多数现代浏览器将缓存代码，这样的方式，已经完成了很多预处理。总是可能编译的东西，也将被缓存在它们的编译状态。 V8是一个开源，快速，JS引擎。如果需要，你可以检查源代码如何确定JS代码的哪些方面被编译，哪些不是。

即使这样，这只是V8的工作原理... JS引擎更多地与你的代码运行速度有关：一些是非常快，其他人不是。有些人在一件事上更快，其他人胜过另一个领域的所有竞争。 更多详情请参阅这里

Compiling the code client side is already being done. True, it takes some time, but not an awful lot. It's quite resource intensive, so most modern browsers will cache the code in such a way that a lot of the preprocessing has been done already. The things that will always be possible to compile, will be cached in their compiled state, too. V8 is an open source, fast, JS engine. If you want, you can check the source on how it's determined what aspects of JS code are compiled, and which aren't.
Even so, that's only how V8 works... The JS engines have more to do with how fast your code runs: Some are very fast, others aren't. Some are faster at one thing, where others outperform all competition on another area. More details can be read here

剥离DOM部分，不会从语言中剥离任何东西。 DOM API 不是JS本身的一部分。 JS是一个非常有表现力，但在核心，小语言，就像C。两者都没有IO功能留给自己的设备，也不能解析一个DOM。为此，JS的浏览器实现可以访问一个DOMParser对象。
$ $ $
你建议一个最小的DOM ...嘿，每个人都有一个改进的DOM API。它远不是关于网络的最好的事情。但是你必须意识到DOM和JS是独立的实体。 DOM（和DOM API）由W3管理，而ECMA负责JS。彼此没有任何关系。这就是为什么DOM不能从JS中被剥离的原因：

Stripping the DOM part, isn't stripping anything from the language. The DOM API, isn't part of JS itself. JS is a very expressive, but in the core, small language, just like C. Both haven't got IO capabilities left to their own devices, nor can they parse a DOM. For that, browser implementations of JS have access to a DOMParser object.
You suggest a minimal DOM... hey, everybody with any sense is all for a revamped DOM API. It's far from the best thing about the web. But you have to realize that the DOM and JS are separate entities. The DOM (and DOM API) are managed by W3, whereas ECMA is responsable for JS. Neither having anything to do with each other. That's why the DOM can't be "stripped" from JS: It was never a part of it to begin with.

因为你比较了JS到C ++：你可以编写可以在Windows和Linux机器上编译的C ++代码，但这不像听起来那么容易。但是，因为你自己指的是C ++，我想你也可能知道这一点。

说到这一点，如果你在C ++和JS之间看到的唯一真正的区别是静态和动态类型，你真的应该花更多的时间来学习JS。

Since you compare JS to C++: You can write C++ code that can be compiled on both windows and Linux machines, but that's not as easy as it sounds. But since you refer to C++ yourself, I think you might know about that, too.
Speaking of which, if the only real difference you see between C++ and JS is the static vs dynamic typing, you really should spend a bit more time learning about JS.

虽然语法本身与C语言类似，但它与Lisp有更多相似之处（即 ）。它不知道类本身，但使用原型...动态类型真的不是那么大的交易，诚实。

While its syntax is C-like, the language itself shares a lot more resemblances with Lisp (ie functional programming). It doesn't know of classes as such, but uses prototypes... the dynamic typing is really not that big of a deal, to be honest.

所以，底部line：

编译JS在每个机器上运行将导致像MS的.NET框架。其背后的哲学是：写一次，无处不在 ...这一切都没有成真。

Java 是 X-platform，但这只是因为它没有编译为本机代码，而是在虚拟机上运行。

最后， ECMAScript标准（JS是其最常见的实现）并不是那么好，而是所有大型竞争对手在该领域的共同努力的结果：Mozilla，Google，Microsoft和一些不相关的瑞士公司。这是一个巨大的妥协。想象这三个大名同意一起编译JS的编译器。 Microsoft将提出其 JScript编译器

So, bottom line:
compiling JS to run on every machine will lead to something like MS's .NET framework. The philosophy behind that was: "Write once, run everywhere"... Which didn't turn out to be true at all.
Java is X-platform, but that's only because it's not compiled to native code, but runs on a virtual machine.
Lastly, the ECMAScript standard (JS being its most common implementation) is not all that good, and is the result of the joint effort of all big competitors in the field: Mozilla, Google, Microsoft and some irrelevant Swiss company. It's one huge compromise. Just imagine those three big names agreeing to make a compiler for JS together. Microsoft will just put forth its JScript compiler as the best, Google will have its own ideas and Mozilla will probably have 3 different compilers ready, depending on what the community wants.

编辑：

You made an edit, clarifying you're talking about client-side JS. Because you felt the need to specify that, I feel as though you're not entirely sure where JS ends, and where the browsers takes over.
JS was designed as a very portable language: it hasn't got IO capabilities, supports multiple development paradigms, and (initially) was a fully interpreted language. True, it was developed with the web in mind, but you could, and some do, use this language to query a database (MongoDB), as an alternative batch scripting language (JScript), or a server-side scripting language (backbone, node.js,...). Some use ECMAScript (the basic standard for JS) to make their own programming language (Yes, I'm talking about Flash ActionScript).

根据用例， JS将被授予访问非本地语言的对象/ API（文档， [Object http] .createServer ， [Object file] .readFileSync 用于DOM访问，web服务器功能和IO）。这些往往构成瓶颈，而不是语言本身。

Depending on the use-case, JS will be given access to objects/API's that aren't native to the language (document, [Object http].createServer, [Object file].readFileSync for DOM access, webserver capabilities, and IO respectively). Those often form the bottlenecks, not the language itself.

由于我暗示广告JS最初是一种解释性语言。正如现在的方式，编译和解释语言之间的分界响铃在过去十年里一直在衰落，老实说。

C / C ++过去是严格编译的语言，但在某些情况下（.NET）C ++代码不需要编译成机器码...

在同时，诸如Python之类的脚本语言被用于许多目的，因为它们通常被认为是编程语言，因为术语脚本语言某种意义上意味着较小的语言 。
$
几年前，随着PHP5的发布，ZendEngine2也发布了。从那时起，PHP被编译为字节码并在虚拟机上运行。您可以使用APC缓存字节码。 bcompiler允许你从PHP代码生成独立的可执行文件，Facebook的HPHPc（已弃用）用于编译PHP到C ++，然后到本地代码。现在，facebook使用HHVM，这是一个自定义虚拟机。 在此了解详情。

As I hinted ad JS was initially an interpreted language. As is the way these days, the division bell between compiled and interpreted languages has been fading for the past decade, to be honest.
C/C++ used to be strictly compiled languages, but in some cases (.NET) C++ code needn't be compiled to machine code anymore...
At the same time, scripting languages like Python, are used for so many purposes they're generally perceived as a programming language, as the term scripting language somehow implies a "lesser language".
A few years ago, with the release of PHP5, the ZendEngine2 was released, too. Since then, PHP is compiled to bytecode and runs on a virtual machine. You can cache the bytecode using APC. The bcompiler allows you to generate standalone executables from PHP code, as does Facebook's HPHPc (deprecated) used to compile PHP to C++, then to native code. Now, facebook uses HHVM, which is a custom virtual machine. Find out more here.

相同的演变可以在JavaScript解释器（现在称为引擎）中看到。他们不是你日常的解析和执行线程的老，因为你仍然认为他们是。在内存管理，JITCompilation（尾堆栈优化甚至），优化和你有什么...
¥b $ b所有伟大的事情，但是这些使得很难确定实际的瓶颈在哪里。每个引擎优化的方式甚至不同于IE6不同于IE10，所以它是不可能精确定位瓶颈。如果一个浏览器对DOM密集型任务需要10秒，另一个浏览器可能只需要1〜2秒。但是，如果相同的浏览器彼此相互检查RegExp对象的性能，引导可能在另一只脚。

让我们不要忘记，在你写博客后 - 关于您的发现，您必须检查是否两个浏览器都没有发布声明加快某些任务的新版本/更新。

The same evolution can be seen in JavaScript interpreters (which are called engines nowadays). They're not your everyday parse-and-execute threads of old, as you still seem to think they are. There's a lot of wizardry going on in terms of memory management, JITCompilation (tail stack optimizing even), optimization and what have you...
All great things, but these make it rather hard to determine where the actual bottlenecks are. The way each engine optimizes differs even more than IE6 differs from IE10, so it's next to impossible to pinpoint the bottlenecks definitively. If one browser takes 10 seconds for a DOM intensive task, another might take only 1~2 seconds. If, however, the same browsers where pitted against each other to check the performance of the RegExp object, the boot might be on the other foot.
Let's not forget that, after you've written your blog-post about your findings, you'll have to check if neither of the browsers has released a new version/update that claims to speed up certain tasks.

这篇关于一个无DOM，静态类型的，提前编译的javascipt代码与本机代码的性能比较如何？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！