What you need to know about JavaScript Engine Switcher 3.0

JavaScript Engine Switcher was originally created as a supporting library and its development was largely determined by the needs of the libraries that used it. In fact, each major version of it solved one or several major tasks necessary for the further development of other libraries:

1. In the first version, the task was to add as many adapter modules as possible for the popular JS engines that support the .NET platform. And this gave Bundle Transformer users some flexibility: on development computers they could use the MSIE module, which supports debugging of JS code using Visual Studio, and on servers that did not have a modern version of Internet Explorer or it was not installed at all, they could V8 module. Some even managed to run the Bundle Transformer in Mono on Linux and Mac using the Jurassic and Jint modules.
2. The main objective of the second version was the implementation of .NET Core support, which was required for the new version of the ReactJS.NET library. Another important task was to create a cross-platform module capable of quickly processing large volumes of JS code (the Jurassic and Jint modules were not suitable for this), and such a module, after a number of improvements, was the ChakraCore module.
3. In the third version, the main focus was on improving integration with the ReactJS.NET library and increasing productivity.

In this article, we will look at some of the innovations of the third version, which for many turned out to be not obvious even after reading the release text and the “How to upgrade applications to version 3.X” section of the documentation: changes in the JsEngineSwitcher class, reorganization of exceptions, more informative error messages, interruption and pre-compiling scripts, the ability to change the maximum stack size in the modules ChakraCore and MSIE, as well as a new module based on NiL.JS.

JsEngineSwitcher class changes

In the new version, the JsEngineSwitcher class implements the IJsEngineSwitcher interface and is no longer a singleton (its instance can be created using the new operator). To get a global instance, use the Current property instead of the Instance property. The Current property, unlike the obsolete Instance property, has the return type IJsEngineSwitcher . Also, the Current property has a setter, with which you can replace the standard implementation with your own:

 JsEngineSwitcher.Current = new MyJsEngineSwitcher(); 

In ASP.NET Core web applications where the JavaScriptEngineSwitcher.Extensions.MsDependencyInjection package is installed, the implementation is replaced using the AddJsEngineSwitcher extension AddJsEngineSwitcher :

 … using JavaScriptEngineSwitcher.Extensions.MsDependencyInjection; … public class Startup { … public void ConfigureServices(IServiceCollection services) { … services.AddJsEngineSwitcher(new MyJsEngineSwitcher(), options => … ) … ; … } … } … 

These changes almost always “break” applications or libraries that use the previous version of JavaScript Engine Switcher. Therefore, you need to make the following changes to your code:

1. Change the type of variables, parameters, or properties from JsEngineSwitcher to IJsEngineSwitcher .
2. Instead of using the Instance property, use the Current property everywhere.

It is also worth noting that for most developers, these changes will not be particularly useful, because their main goal was to simplify unit tests (for example, blocking was used in the unit tests of the ReactJS.NET library, and now you can do without them ).

Reorganization of exceptions

Prior to the third version, most of the errors of JS engines turned into exceptions of the JsRuntimeException type, and only errors that occurred during the engine initialization process turned into a JsEngineLoadException . There was also a base class JsException , from which the two types of exceptions listed above inherited, which allowed to intercept absolutely all the errors that occurred during the work of JS engines. Despite obvious shortcomings, such an organization of exceptions fit well into the concept of a unified interface for accessing the basic features of JS engines.

But when realizing the possibilities of interruption and preliminary compilation of scripts (I will talk about them in the next sections), a need arose for a new approach to the organization of exceptions. The first thing to do was to add a new exception type - JsInterruptedException , which was necessary to notify the user about the interruption of script execution. Then it was necessary to explicitly divide all errors that occurred while processing scripts into two groups: compilation errors (syntax analysis) and runtime errors. Also required to separate all sorts of specific errors Chakra and V8, which were not associated with the processing of scripts. It was also necessary to take into account the presence in the Jint engine of an exception that occurs when the script execution timeout (timeout) expires. As a result, a new approach to the organization of exceptions was formed, which can be represented as the following hierarchical structure:

• JsException
  
  • JsEngineException
    
    • JsEngineLoadException
  • JsFatalException
  • JsScriptException
    
    • JsCompilationException
    • JsRuntimeException
      
      • JsInterruptedException
      • JsTimeoutException
  • JsUsageException
• JsEngineNotFoundException ^*

* - this exception occurs not at the level of the JS engine, but at the level of JavaScript Engine Switcher.

I think that the hierarchy of exceptions presented above does not need comments, because the names of the exceptions speak for themselves. With this approach, we get not only more information about the causes of the error, but we can more flexibly handle certain types of exceptions.

Unified error message format

Another problem with previous versions of JavaScript Engine Switcher was the difficulty in locating errors that occurred during script processing. It was difficult to understand exactly where the error occurred from the Message exception property, so we had to analyze other exception properties, which was not always convenient. In addition, a set of existing properties was also insufficient.

Therefore, 2 new properties have been added to the JsScriptException class:

1. Type - type of JavaScript error (for example, SyntaxError or TypeError );
2. DocumentName is the name of the document (usually derived from the values ​​of the following parameters: documentName of the Execute and Evaluate methods, path the ExecuteFile method, resourceName the ExecuteResource method, etc.);

One new property has also been added to the JsRuntimeException class - CallStack , which contains a string representation of the call stack.

Previously, the Message property simply copied a value from a similar property of the original .NET exception or a string representation of a JavaScript error. Often, error messages in different JS engines differed not only in the format, but also in the amount of useful information presented in them. For example, due to the lack of information about the row and column numbers in some error messages, the developers of the ReactJS.NET library were forced to override the exceptions obtained from the JavaScript Engine Switcher.

Therefore, I decided to generate my own error messages at the level of adapter modules that would have a single (unified) format. This format uses all available error information: type, description, document name, line number, column number, code fragment, and call stack. As a basis for the new format, I took the error format from the Microsoft ClearScript library.

Below are the messages about the same compilation error that were generated by different adapter modules:

 ChakraCore ========== SyntaxError: Unexpected identifier after numeric literal at declinationOfSeconds.js:12:23 -> caseIndex = number % 1O < 5 ? number % 10 : 5; Jint ==== SyntaxError: Unexpected token ILLEGAL at declinationOfSeconds.js:12:25 Jurassic ======== SyntaxError: Expected operator but found 'O' at declinationOfSeconds.js:12 MSIE в режиме Classic ===================== SyntaxError: Expected ';' at declinationOfSeconds.js:12:25 -> caseIndex = number % 1O < 5 ? number % 10 : 5; MSIE в режиме Chakra ActiveScript ================================= SyntaxError: Expected ';' at declinationOfSeconds.js:12:25 -> caseIndex = number % 1O < 5 ? number % 10 : 5; MSIE в режиме Chakra IE JsRT ============================ SyntaxError: Expected ';' at 12:25 -> caseIndex = number % 1O < 5 ? number % 10 : 5; MSIE в режиме Chakra Edge JsRT ============================== SyntaxError: Unexpected identifier after numeric literal at declinationOfSeconds.js:12:23 -> caseIndex = number % 1O < 5 ? number % 10 : 5; NiL === SyntaxError: Unexpected token 'O' at 12:25 V8 == SyntaxError: Invalid or unexpected token at declinationOfSeconds.js:12:24 -> caseIndex = number % 1O < 5 ? number % 10 : 5; Vroom ===== SyntaxError: Unexpected token ILLEGAL at declinationOfSeconds.js:12:24 

A similar example for a runtime error:

 ChakraCore ========== TypeError: Unable to get property 'Ч' of undefined or null reference at transliterate (russian-translit.js:929:4) -> newCharValue = typeof charMapping[charValue] !== 'undefined' ? at Global code (Script Document:1:1) Jint ==== TypeError: charMapping is undefined at russian-translit.js:929:26 Jurassic ======== TypeError: undefined cannot be converted to an object at transliterate (russian-translit.js:929) at Global code (Script Document:1) MSIE в режиме Classic ===================== TypeError: 'undefined' is null or not an object at russian-translit.js:929:4 MSIE в режиме Chakra ActiveScript ================================= TypeError: Unable to get property 'Ч' of undefined or null reference at russian-translit.js:929:4 MSIE в режиме Chakra IE JsRT ============================ TypeError: Unable to get property 'Ч' of undefined or null reference at transliterate (russian-translit.js:929:4) at Global code (Script Document:1:1) MSIE в режиме Chakra Edge JsRT ============================== TypeError: Unable to get property 'Ч' of undefined or null reference at transliterate (russian-translit.js:929:4) at Global code (Script Document:1:1) NiL === TypeError: Can't get property "Ч" of "undefined" V8 == TypeError: Cannot read property 'Ч' of undefined at transliterate (russian-translit.js:929:37) -> newCharValue = typeof charMapping[charValue] !== 'undefined' ? at Script Document:1:1 Vroom ===== TypeError: Cannot read property 'Ч' of undefined at russian-translit.js:929:37 

From the examples it can be seen that some JS engines give us completely different error descriptions and column numbers, and not always we can get a complete set of error data, but even despite these shortcomings, the unified format gives us more information about the location of the error than original error messages.

Tips for deploying native builds

The main cause of errors when working with the second version of JavaScript Engine Switcher was that many developers forgot to install NuGet packages containing native assemblies for ChakraCore and V8 modules. At one time, this post was even devoted to a post in the ReactJS.NET bugtracker (a Russian translation is also available). Now, this is mostly a bug for newbies who, for some reason, have not read the documentation.

The authors of ReactJS.NET tried to minimize the number of such errors with the help of hints inside error messages, but the not very successful implementation of this approach led to even more confusion . The idea of ​​the prompts was good, but it required a fundamentally different implementation, namely, the implementation of JS engines at the level of adapter modules. In the new version of JavaScript Engine Switcher, such hints are added to the error message when wrapping DllNotFoundException and TypeLoadException exceptions into a JsEngineLoadException exception (see the implementation examples for ChakraCore , V8, and Vroom modules). Moreover, these tips are intelligent, because their generation takes into account a number of factors: the type of operating system, processor architecture and runtime (.NET Framework, .NET Core or Mono).

For example, if you use the ChakraCore module without a native build in a 64-bit process on the Windows operating system, the error message will look like this:

Failed to create an instance of the ChakraCoreJsEngine. Most likely it happened, because the dependencies were not found. Try to install the JavaScriptEngineSwitcher.ChakraCore.Native.win-x64 package via NuGet. In addition, you still need to install the Microsoft Visual C ++ Redistributable for Visual Studio 2017 ( https://www.visualstudio.com/downloads/#microsoft-visual-c-redistributable-for-visual-studio-2017 ).

The error message prompts you to install the NuGet package JavaScriptEngineSwitcher.ChakraCore.Native.win-x64, and also mentions that ChakraCore for Windows requires a Microsoft Visual C ++ redistributable component for Visual Studio 2017 to work. If this error will occur in a 32-bit process, the user will be prompted to install the JavaScriptEngineSwitcher.ChakraCore.Native.win-x86 package.

A similar error message on Linux in the .NET Core environment will look like this:

Failed to create an instance of the ChakraCoreJsEngine. Most likely it happened, because of its dependencies was not found. Try to install the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package via NuGet.

In this case, you will be prompted to install the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package.

When launched in Mono, another hint will be displayed:

... JavaScriptEngineSwitcher.ChakraCore.Native.linux- * package

Since the JavaScriptEngineSwitcher.ChakraCore.Native.linux-x64 package is only compatible with .NET Core, the prompt will link to instructions for manually deploying the native build in Linux.

You can still give many examples, but this makes no sense.

Interrupting Script Execution

When we give users the ability to execute arbitrary JS code on the server, we face one very serious problem - we don’t know how long it will take to execute this code. This may be a large amount of non-optimal code or a code that starts an infinite loop. In any case, this will be code that we cannot control, which will consume our server resources indefinitely. In order to somehow control this process, we need the ability to interrupt the execution of scripts. When using engines written in pure .NET (for example, Jint, Jurassic or NiL.JS), we can always start executing JS-code as a task with the possibility of cancellation, but this approach will not work for other engines. Fortunately for us, the engines written in C ++ have built-in mechanisms for interrupting scripts.

To provide access to these mechanisms, the SupportsScriptInterruption property and the Interrupt method IJsEngine been added to the IJsEngine interface. Since not all engines support this feature, you should always check the value of the SupportsScriptInterruption property before calling the Interrupt method (if you had to manually start the garbage collector in previous versions of JavaScript Engine Switcher, you will immediately understand what I am talking about):

 if (engine.SupportsScriptInterruption) { engine.Interrupt(); } 

Moreover, it is necessary to call this method in a separate thread other than the one in which the scripts are executed. After calling the Interrupt method, all previously run Evaluate , Execute* and CallFunction will be completed by throwing a JsInterruptedException exception.

Since this API is low-level, for the tasks described in the beginning of the section it is recommended to use extension methods like this:

 using System; #if !NET40 using System.Runtime.ExceptionServices; #endif using System.Threading; using System.Threading.Tasks; using JavaScriptEngineSwitcher.Core; #if NET40 using JavaScriptEngineSwitcher.Core.Extensions; #endif using JavaScriptEngineSwitcher.Core.Resources; … /// <summary> /// Extension methods for <see cref="IJsEngine"/> /// </summary> public static class JsEngineExtensions { /// <summary> /// Evaluates an expression within a specified time interval /// </summary> /// <typeparam name="T">Type of result</typeparam> /// <param name="engine">JS engine</param> /// <param name="expression">JS expression</param> /// <param name="timeoutInterval">Interval to wait before the /// script execution times out</param> /// <param name="documentName">Document name</param> /// <returns>Result of the expression</returns> /// <exception cref="ObjectDisposedException"/> /// <exception cref="ArgumentNullException"/> /// <exception cref="ArgumentException"/> /// <exception cref="JsCompilationException"/> /// <exception cref="JsTimeoutException"/> /// <exception cref="JsRuntimeException"/> /// <exception cref="JsException"/> public static T Evaluate<T>(this IJsEngine engine, string expression, TimeSpan timeoutInterval, string documentName) { if (engine == null) { throw new ArgumentNullException(nameof(engine)); } if (engine.SupportsScriptInterruption) { using (var timer = new Timer(state => engine.Interrupt(), null, timeoutInterval, #if NET40 new TimeSpan(0, 0, 0, 0, -1))) #else Timeout.InfiniteTimeSpan)) #endif { try { return engine.Evaluate<T>(expression, documentName); } catch (JsInterruptedException e) { throw new JsTimeoutException( Strings.Runtime_ScriptTimeoutExceeded, e.EngineName, e.EngineVersion, e ); } } } else { #if NET40 Task<T> task = Task.Factory.StartNew(() => #else Task<T> task = Task.Run(() => #endif { return engine.Evaluate<T>(expression, documentName); }); bool isCompletedSuccessfully = false; try { isCompletedSuccessfully = task.Wait(timeoutInterval); } catch (AggregateException e) { Exception innerException = e.InnerException; if (innerException != null) { #if NET40 innerException.PreserveStackTrace(); throw innerException; #else ExceptionDispatchInfo.Capture(innerException).Throw(); #endif } else { throw; } } if (isCompletedSuccessfully) { return task.Result; } else { throw new JsTimeoutException( Strings.Runtime_ScriptTimeoutExceeded, engine.Name, engine.Version ); } } } … } … 

This method is an add-on over the Evaluate<T> engine method, which allows setting the timeout for the script execution using the timeoutInterval parameter. The principle of this extension method is very simple. First, we check if our engine supports the built-in interrupt mechanism. If it timeoutInterval , then we create an instance of the Timer class, which, through the timeoutInterval parameter, starts the Interrupt method, then we call the Evaluate<T> engine method, and in case of an error, we catch the JsInterruptedException exception and wrap it in a JsTimeoutException . If the engine does not support interrupts, then create an instance of the Task class that runs the Evaluate<T> engine method, then set the task timeout interval equal to the value from the timeoutInterval parameter, and if the task timed out, then throw an exception of type JsTimeoutException . The following is an example of using this extension method:

 using System; … using JavaScriptEngineSwitcher.Core; using JavaScriptEngineSwitcher.Core.Helpers; … class Program { … static void Main(string[] args) { const string expression = @"function getRandomInt(minValue, maxValue) { minValue = Math.ceil(minValue); maxValue = Math.floor(maxValue); return Math.floor(Math.random() * (maxValue - minValue + 1)) + minValue; } function sleep(millisecondsTimeout) { var totalMilliseconds = new Date().getTime() + millisecondsTimeout; while (new Date().getTime() < totalMilliseconds) { } } var randomNumber = getRandomInt(1, 10); sleep(randomNumber * 1000); randomNumber;"; using (IJsEngine engine = JsEngineSwitcher.Current.CreateDefaultEngine()) { try { int result = engine.Evaluate<int>(expression, TimeSpan.FromSeconds(3), "randomNumber.js"); Console.WriteLine("результат = {0}", result); } catch (JsTimeoutException) { Console.WriteLine("Во время вычисления выражения JavaScript " + "было превышено время ожидания!"); } catch (JsException e) { Console.WriteLine("Во время работы JavaScript-движка произошла " + "ошибка!"); Console.WriteLine(); Console.WriteLine(JsErrorHelpers.GenerateErrorDetails(e)); } } } … } … 

Using the extension method, we calculate the result of a JS expression. The result of the expression is a random integer, and this number is also the number of seconds by which the execution of this expression is delayed. Also, when calling the extension method, we specify a wait interval of 3 seconds. Since the time to calculate the expression varies from 1 to 10 seconds, in one case the result of the expression will be displayed on the console, and in the other the message about waiting time is displayed.

It should be easy for you to remake this extension method to call other methods of the engine (for example, under the Execute* , CallFunction or other overloaded versions of the Evaluate method). While I have not yet decided whether I will add such extension methods to the library itself, because it is not yet clear how much they will be in demand.

Pre-compiling scripts

I was asked to add support for pre-compiling scripts back in 2015 . At that moment, it was not clear how such a function could fit into the concept of a unified interface. But as time went on, support for special features such as garbage collection and script interruption began to appear in JavaScript Engine Switcher. At the last stages of work on the third version, the turn reached the preliminary compilation.

Using precompilation, you can compile the script once, and then use it many times to initialize the JS engines. Due to the fact that the pre-compiled script does not require syntactic analysis, the initialization of the engines will be faster.

At the moment, 5 modules-adapters support preliminary compilation: ChakraCore, Jint, Jurassic, MSIE (only in JsRT-modes) and V8. To provide access to the corresponding engine mechanisms, the SupportsScriptPrecompilation property and 3 new methods were added to the IJsEngine interface: Precompile , PrecompileFile and PrecompileResource . Precompile* methods return an instance of an object that implements the IPrecompiledScript interface. This object is a pre-compiled script that can be used by different instances of engines (for these purposes serves as an overloaded version of the Execute method). Consider a simple example of using this API:

 using System; … using JavaScriptEngineSwitcher.Core; using JavaScriptEngineSwitcher.Core.Helpers; … class Program { … static void Main(string[] args) { const string sourceCode = @"function declinationOfSeconds(number) { var result, titles = ['секунда', 'секунды', 'секунд'], titleIndex, cases = [2, 0, 1, 1, 1, 2], caseIndex ; if (number % 100 > 4 && number % 100 < 20) { titleIndex = 2; } else { caseIndex = number % 10 < 5 ? number % 10 : 5; titleIndex = cases[caseIndex]; } result = number + ' ' + titles[titleIndex]; return result; }"; const string functionName = "declinationOfSeconds"; const int itemCount = 4; int[] inputSeconds = new int[itemCount] { 0, 1, 42, 600 }; string[] outputStrings = new string[itemCount]; IJsEngineSwitcher engineSwitcher = JsEngineSwitcher.Current; IPrecompiledScript precompiledCode = null; using (var engine = engineSwitcher.CreateDefaultEngine()) { if (!engine.SupportsScriptPrecompilation) { Console.WriteLine("{0} версии {1} не поддерживает " + "предварительную компиляцию скриптов!", engine.Name, engine.Version); return; } try { precompiledCode = engine.Precompile(sourceCode, "declinationOfSeconds.js"); engine.Execute(precompiledCode); outputStrings[0] = engine.CallFunction<string>(functionName, inputSeconds[0]); } catch (JsCompilationException e) { Console.WriteLine("Во время предварительной компиляции скрипта " + "произошла ошибка!"); Console.WriteLine(); Console.WriteLine(JsErrorHelpers.GenerateErrorDetails(e)); return; } catch (JsException e) { Console.WriteLine("Во время работы JavaScript-движка произошла " + "ошибка!"); Console.WriteLine(); Console.WriteLine(JsErrorHelpers.GenerateErrorDetails(e)); return; } } for (int itemIndex = 1; itemIndex < itemCount; itemIndex++) { using (var engine = engineSwitcher.CreateDefaultEngine()) { try { engine.Execute(precompiledCode); outputStrings[itemIndex] = engine.CallFunction<string>( functionName, inputSeconds[itemIndex]); } catch (JsException e) { Console.WriteLine("Во время работы JavaScript-движка " + "произошла ошибка!"); Console.WriteLine(); Console.WriteLine(JsErrorHelpers.GenerateErrorDetails(e)); return; } } } for (int itemIndex = 0; itemIndex < itemCount; itemIndex++) { Console.WriteLine(outputStrings[itemIndex]); } } … } … 

Сначала мы создаем движок, с помощью которого скомпилируем код функции для склонения числительных. После чего используем свойство SupportsScriptPrecompilation для того, чтобы проверить поддерживает ли движок предварительную компиляцию, если нет, то информируем об этом пользователя. Затем с помощью метода Precompile компилируем скрипт, если код скрипта содержит синтаксические ошибки, то будет выброшено исключения типа JsCompilationException . C помощью метода Execute загружаем скомпилированный скрипт в память движка, т.е. производим его инициализацию. Затем с помощью метода CallFunction вызываем функцию declinationOfSeconds и сохраняем полученный результат в массив. После чего происходит уничтожение движка. Несмотря на то, что движок был уничтожен, скомпилированный им скрипт продолжает существовать и может быть использован другими движками. Далее мы создаем еще 3 движка и каждый из них инициализируем скомпилированным скриптом. После инициализации, как и в случае с самым первым движком, вызываем функцию и сохраняем ее результат в массив. В конце примера выводим содержимое этого массива на экран, чтобы удостовериться в том, что инициализация движков прошла без ошибок.

Предыдущий пример хоть и наглядно показывает, как можно использовать предварительную компиляцию, но является немного искусственным. В реальных проектах, скорее всего, вы будете использовать пулинг движков и хранить скомпилированные скрипты в кэше. Именно такой подход используется в проекте ReactJS.NET. Пулинг движков там реализован с помощью библиотеки JSPool , а выбор реализации кэша зависит от используемого фреймворка ( System.Runtime.Caching.MemoryCache для .NET Framework 4.X, System.Web.Caching.Cache для ASP.NET 4.X и Microsoft.Extensions.Caching.Memory.IMemoryCache для ASP.NET Core). Не буду вдаваться в детали реализации, потому что это займет слишком много времени (при желании вы всегда можете ознакомиться с исходным кодом ). Лучше вместо этого рассмотрим, как использовать предварительную компиляцию скриптов в ReactJS.NET.

По умолчанию предварительная компиляция в ReactJS.NET отключена. Поскольку эта возможность пока считается экспериментальный и еще не применялась на реальных высоконагруженных сайтах. Чтобы ее включить нужно присвоить конфигурационному свойству AllowJavaScriptPrecompilation значение равное true .

В ASP.NET 4.X для этого вам нужно отредактировать файл App_Start/ReactConfig.cs :

 … public static class ReactConfig { public static void Configure() { ReactSiteConfiguration.Configuration … .SetAllowJavaScriptPrecompilation(true) … ; … } } … 

В ASP.NET Core эта настройка производится в файле Startup.cs :

 … public class Startup { … public void Configure(IApplicationBuilder app, IHostingEnvironment env) { … app.UseReact(config => { config … .SetAllowJavaScriptPrecompilation(true) … ; }); app.UseStaticFiles(); … } } … 

В конце раздела я хочу показать вам, как предварительная компиляция влияет на производительность. В качестве примера рассмотрим результаты бенчмарка JsExecutionBenchmark , реализованного средствами библиотеки BenchmarkDotNet . В качестве исполняемого скрипта здесь используется небольшая JS-библиотека для транслитерации русского текста латиницей. Весит она всего 14,9 Кбайт, но этого нам будет достаточно, чтобы увидеть эффект от применения предварительной компиляции. Во время тестирования использовалась последняя на текущий момент версия JavaScript Engine Switcher (версия 3.0.4).

Начнем с результатов, полученных при запуске в среде .NET Framework 4.7.2:

Наибольший выигрыш в процентном выражении мы получаем для движков, написанных на чистом .NET — скорость выполнения скрипта на Jurassic вырастает 5,79 раз, а на Jint в 1,75 разa. При работе этих движков в 2 раза сокращается объем выделяемой памяти, и соответственно более чем в 2 раза сокращается количество операций по сборке мусора. За счет снижения количества операций по сборке мусора мы получаем частичный прирост в скорости выполнения скрипта. Главная причина прироста скорости в Jurassic, также является и причиной его наихудшего результата в этом тесте: Jurassic всегда компилирует JS-код в IL-код средствами Reflection.Emit, а затем исполняет его. Именно на этапе компиляции происходит основная потеря производительности, а поскольку при предварительной компиляции это происходит всего один раз, мы и получаем выигрыш в производительности. Jint же наоборот является интерпретатором и в результате предварительной компиляции возвращает .NET-объект, представляющий абстрактное синтаксическое дерево. В случае с Jint мы экономим ресурс за счет того, что производим всего одну операцию синтаксического разбора и храним в памяти одно АСД. По результатам данного теста можно подумать, что Jint является самым быстрым движком, но это не так, потому что по мере роста объема выполняемого кода его производительность будет падать. Вообще Jint и Jurassic показывают наихудшие результаты при обработке больших объемов кода.

Лучший результат среди оберток над движками, написанными на C++, показывает MSIE в режиме Chakra IE JsRT — скорость выполнения увеличивается на 26,93%. После него идет ChakraCore (18,96%), потом V8 (4,71%) и MSIE в режиме Chakra Edge JsRT показывает худший результат (0,85%). Для меня до сих пор остается загадкой почему движок из Internet Explorer оказался быстрее движка Edge. Вообще столь скромные результаты для данного типа движков можно объяснить следующим образом. Мы получаем скомпилированный скрипт от движка в сериализованном виде (в виде массива байт) и сохраняем его в управляемой памяти. Вы можете заметить, что в последнем столбце таблицы из-за появления этого массива увеличился объем выделяемой памяти на 12-17 Кбайт (в этом тесте мы измеряем только управляемую память). При инициализации движка скомпилированным скриптом производится десериализация этого массива. Также добавьте к этому затраты на маршалинг. Тем не менее выигрыш в производительности все равно ощутим.

Запуск тестов в среде .NET Core 2.0 дает следующие результаты (модуль V8 отсутствует, потому что библиотека Microsoft ClearScript, на которой он основан, не поддерживает .NET Core):

В целом мы получили похожие результаты. Единственное, что бросается в глаза — результат MSIE в режиме Chakra Edge JsRT улучшился (7,69%). Также в данном случае при использовании предварительной компиляции движками семейства Chakra снижается потребление управляемой памяти.

Возможность изменения максимального размера стека в модулях ChakraCore и MSIE

Размер стека в движках, разработанных Microsoft, ограничивается размером стека потока, в котором выполняется движок. Поскольку в современных версиях IIS он достаточно мал (256 Кбайт для 32-разрядной версии и 512 Кбайт для 64-разрядной), то при запуске в ASP.NET больших JS-библиотек (например, компилятора TypeScript) происходит переполнение стека. Эта проблема уже давно решается в JavaScript Engine Switcher путем создания отдельного потока для выполнения этих движков. Раньше при создании таких потоков размер стека был жестко закодирован в исходном коде, и совпадал с максимальным размером стека в Node.js (492 Кбайт для 32-разрядного процесса и 984 Кбайт для 64-разрядного). Со временем выяснилось, что не всем хватает такого размера, а кто-то наоборот хочет его уменьшить. Поэтому в третьей версии в настройки модулей ChakraCore и MSIE была добавлена опция MaxStackSize , с помощью которой вы можете задать размер стека в байтах. По умолчанию используется то же значение в стиле Node.js. Если присвоить этому свойству значение равное нулю, то в качестве максимального размера стека будет использоваться значение из заголовка исполняемого файла.

Новый модуль на основе NiL.JS

В третьей версии появился новый модуль-адаптер NiL , который создан на основе движка NiL.JS . NiL.JS — это еще один JS-движок, написанный на чистом .NET. Его первая версии вышла в 2014 году, но он не получил такую популярность как Jurassic и Jint. Его основное достоинство — это производительность. В качестве примера можно привести результаты того же бенчмарка, что использовался в разделе про предварительную компиляцию.

При запуске в среде .NET Framework 4.7.2 мы получим следующие результаты:

Результаты запуска в среде .NET Core 2.0 отличаются незначительно:

Результаты этих тестов можно даже не комментировать. Такие впечатляющие результаты были получены благодаря нестандартным решениям, которые использовал его автор (подробности вы можете узнать из его статей на Хабре ). Стоит также заметить, что авторы Jint тоже не сидели сложа руки и с 2016 года работают над третьей версией своего движка, одной из задач которой является повышение производительности. Если верить бенчмарку для версии 3.0.0 Beta 1353 , то предварительная версия Jint выполняет скрипты в 2,4 раза быстрее, чем NiL.JS версии 2.5.1200, и показатели использования памяти у них практически совпадают.

Есть у NiL.JS и недостатки. Все идет хорошо пока мы выполняем на нем какой-то простой код, но когда мы пытаемся запустить какие-нибудь популярные библиотеки, то начинают возникать ошибки. Из всех модулей Bundle Transformer, использующих JavaScript Engine Switcher, мне удалось запустить только Hogan и Handlebars, та же ситуация и с ReactJS.NET. В ближайшее время я собираюсь задокументировать все эти ошибки и передать их автору NiL.JS.

Links

1. Страница проекта JavaScript Engine Switcher на GitHub
2. Документация JavaScript Engine Switcher
3. Перевод моего поста «Заблуждения о JavaScript Engine Switcher 2.X»
4. Страница проекта JSPool на GitHub
5. Сайт проекта ReactJS.NET
6. Страница проекта ReactJS.NET на GitHub