Преимущества механизмов JavaScript

V8 - самый быстрый, потому что он компилирует все JS к машиностроительному коду.

Spidermonkey (какое использует FF) тоже быстро, но компилируется в промежуточный байт-код, а не машинный код. Это главное различие с v8. Редактирование - новые выпуски Firefox поставляются с более новым вариантом Spidemonkey; Tracemonkey. Tracemonkey делает JIT Compilation критических частей, и, возможно, другие умные оптимизации.

Rhino компилирует JavaScript в классы Java, что позволяет вам в основном написать приложения «Java» в JavaScript. Rhino также используется в качестве способа интерпретации JS на бэкэнде и манипулировать им и иметь полное понимание кода, такое как отражение. Это используется, например, компрессором YUI.

Причина, по которой Rhino используется вместо V8 повсюду, вероятно, потому что V8 относительно новое, поэтому многие проекты уже использовали Rhino / Spidermonkey в качестве своего двигателя JS, например, виджеты Yahoo. (Я предполагаю, что это то, что вы имеете в виду с «сценариями на рабочих столах»)

редактировать- Эта ссылка также может дать некоторое понимание того, почему Spidermonkey настолько широко принят. Какой двигатель JavaScript вы бы встроили в ваше приложение?

Чтобы ответить на вопрос, почему нативный код VS BYTE код ...

Нативный код быстрее и для Google стратегический выбор, потому что они планируют JS один из них, по крайней мере, Chromeos.

Хорошее видео Об этом вопросе размещено на канале9 с интервью на Ларс Бак, который находится в V8

Если вы хотите увидеть, как укладываются различные двигатели JavaScript в браузере, установите Safari 4 (да, он тоже работает на Windows!), Chrome V8, Firefox 3.5 и IE IE Если вы находитесь в Windows) и запустите тестов:

http://www2.webkit.org/perf/sunspider-0.9/sunspider.html-0.9/sunspider.html

Я верю, как сказал выше, но новый Firefox 3.5 использует Tracemonkey, что Также компилируется для промежуточного кода на лету с использованием некоторой формы JIT. Таким образом, он должен сравниться с V8 несколько выгодно. По крайней мере, это не будет 10x медленнее, чем V8, как Firefox 3 Spidermonkey (без джита).

Для меня ... Safari 4.0.3 составил 2,5 раза быстрее, чем Tracemonky в Firefox 3.5.3 на Win XP. IE8 был намного медленнее. У меня нет Chrome установлен в данный момент.

Не знаю о носорогах, составляющих Java Bytecode. Если он по-прежнему интерпретирует динамические особенности JavaScript, таких как возможность добавлять атрибуты для объектов экземпляров во время выполнения (пример obj.somenewattribute = "quotevalue", который допускается в JavaScript) ... Я не так уверен, что это совершенно компилировано «Bytecode, и вы можете не получить лучшую производительность, кроме того, что вам не нужно компилировать исходный код источника JavaScript каждый раз, когда ваш JavaScript работает. Помните, что JavaScript позволяет очень динамичный синтаксис, такой как Eval («x = 10; y = 20; z = x * y»); Это означает, что вы можете создать строки кода, который собирается во время выполнения. Вот почему я бы подумал, что Rhino будет смешанным режимом интерпретации / скомпилирован, даже если вы скомпилировали JVM Bytecode.

JVM все еще переводчик, хотя и очень хороший с поддержкой JIT. Поэтому мне нравится думать о Rhino-on-JVM как 2 слоя переводчика (переводчик-переводчик) или переводчик ^ 2. Принимая во внимание, что большинство ваших других двигателей JavaScript написаны в C, а как таковые должны выполнять больше похожего на интерпретатор ^ 1. Каждый слой интерпретатора может добавлять 5-10x разлагаться на производительности по сравнению с C или C ++ (Ref Perl или Python или Ruby), но с JIT HIT производительностью может быть намного ниже порядка 2-4х. И JVM имеет один из самых надежных и зрелых JIT-двигателей.

Итак, ваш пробег определенно варьируется, и вы, вероятно, выиграете от выполнения некоторых серьезных ориентиров, если вы хотите реальный ответ для вашего предполагаемого приложения на собственные аппаратные и ОС.

Rhino не может быть слишком ужасно медленно, так как я знаю, что многие люди используют его. Я думаю, что это главное апелляция - это не его скорость, но тот факт, что это просто для кода / света / встроенный / интерпретатор, который имеет крючки в библиотеки Java, что делает его идеальным для сценариев / конфигурации / расширяемости вашего программного обеспечения. Некоторые текстовые редакторы, такие как UltraEdit, даже встраивают JavaScript в качестве альтернативного сценариев макроса. Кажется, каждый программист сможет довольно легко наткнуться через JavaScript, поэтому легко подобрать.

Одним из преимуществ Rhino является то, что он проходит почти в любом месте, где работает JVM. По моему опыту, пытаясь получить автономный Tracemonkey или Spidermonkey, чтобы построить и запустить из командной строки, может быть немного больно на системах, таких как Windows. И встраивание в вашем собственном приложении может быть еще больше времени потребления.Но окупаемость наличия встроенного языка будет стоить для большого проекта, по сравнению с необходимостью «катиться своим собственным» решением Mini Scripting, если это то, что вы хотите сделать.

Скрипты с Rhino действительно просто, если у вас есть Java и JAR Rhino, вы просто пишете свой JavaScript и запустите его из командной строки. Я использую это все время для простых задач.

Вы ищете PGTune ?

Существуют различные подходы к выполнению JavaScript, даже при выполнении JIT. V8 и Nitro (ранее известный как Escrirefish Extreme), выберите, чтобы сделать целый метод Йит, что означает, что они скомпилируют весь код JavaScript в соответствии с нативными инструкциями, когда они столкнутся с скриптом, а затем просто выполните это, как если бы он был скомпилирован C-код. SPIDERMONKEY использует вместо этого «трассировка» jit, которая сначала компилирует скрипт к Bytecode и интерпретащает его, но следит за исполнением, ищет «горячих пятен», таких как петли. Когда он обнаруживает один, затем компилируется только тот горячий путь к машиностроительному коду и выполняет, что в будущем.

Оба подхода имеют выделение и недостатки. Целый метод jit гарантирует, что весь JavaScript, который выполнен, будет скомпилирован и работать как машинный код и не интерпретируется, что в целом должно быть быстрее. Однако в зависимости от реализации может означать, что двигатель проводит время компиляции кода, который никогда не будет выполнен или может быть выполнен только один раз, и не является критическим. Кроме того, этот скомпилированный код должен храниться в памяти, поэтому это может привести к увеличению использования памяти.

Tracing Jit, как реализован в Spidermonkey, может производить чрезвычайно специализированный код по сравнению с цельным методом JIT, поскольку он уже выполнил код и может спекулировать на типов переменных (таких как обрабатывающая переменную индекса в контуре для цикла, как Нативное целое число), где целый метод JIT должен будет относиться к переменной в качестве объекта, поскольку JavaScript является невыполнен, и тип может измениться (Spidermonkey просто «падает» трассировки, если предположение не удается, и возврат к интерпретации Bytecode). Тем не менее, отслеживание JIT Spidermonkey в настоящее время не работает эффективно на коде со многими ветвями, поскольку следы оптимизированы для односторонних путей выполнения. Кроме того, есть некоторые накладные расходы, участвующие в казни для мониторинга, прежде чем решить, чтобы скомпилировать трассировку, а затем переключать выполнение в этот след. Кроме того, если Tracer делает предположение, которое позже нарушено (например, тип переменного смены), стоимость падения следов и переключения назад к интерпретации, вероятно, будет выше, чем с цельным методом JIT.