缺少DOM，静态类型，提前编译的javascript代码与本机代码在性能方面如何比较? [英] How would a DOM-less,statically typed, ahead-of-time-compiled javascript 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并未用于资源密集型Web应用程序(例如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 Canvas，但是，如果值得在性能上获得好处，则从理论上讲，可以通过修改技术来消除这种情况.假设回答时可以使用无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.

我在谈论客户端编译.

推荐答案

重要提示:
您似乎主张提倡使用JS剥离，静态类型的可编译版本.显示的第一件事是您对JS是什么一无所知:一种 multi-paradigm 编程语言，它支持基于 Prototype的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以及具有不同移动浏览器的平板电脑和智能手机...
即使您确实设法撰写&编译可在所有平台上运行的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 <​​em>剥离" 的原因:从一开始它就从来都不是其中的一部分.

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.

所以，最重要的是:
编译要在每台计算机上运行的JS会导致类似MS的.NET框架.其背后的理念是:写一次，到处运行" ...事实证明，这根本不是真的.
Java 是 X平台，但这仅仅是因为它没有被编译为本地代码，而是在虚拟机上运行.
最后，ECMAScript标准(JS是其最常用的实现)并不是那么好，它是该领域所有主要竞争对手(Mozilla，Google，Microsoft和一些无关的瑞士公司)共同努力的结果.这是一个巨大的折衷.试想一下这三个大人物同意共同为JS编译器.微软将发布其 JScript编译器最好，Google将有自己的想法，Mozilla可能会准备3种不同的编译器，具体取决于社区的需求.

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.

修改:
您进行了编辑，以澄清您在谈论客户端JS.因为您觉得有必要指定它，所以我觉得您不太确定JS的结束位置以及浏览器的接管位置.
JS被设计为一种可移植的语言:它没有IO功能，支持多种开发范例，并且(最初)是一种完全解释的语言.的确，它是在考虑到Web的情况下开发的，但是您(有些人确实可以)使用这种语言来查询数据库(MongoDB)，替代的批处理脚本语言(JScript)或服务器端脚本语言(主干， node.js，...).有些人使用ECMAScript(JS的基本标准)来制作自己的编程语言(是的，我在谈论Flash ActionScript).

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的权限(分别为document，[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之类的脚本语言被用于许多目的，它们通常被认为是一种编程语言，因为术语 scripting language 在某种程度上意味着较少的语言" em>.
几年前，随着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(尾栈优化甚至)，优化以及您有什么...
所有伟大的事情，但是这些使确定实际瓶颈在哪里变得相当困难.每个引擎优化的方式甚至比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，静态类型，提前编译的javascript代码与本机代码在性能方面如何比较?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！