📜 ⬆️ ⬇️

Speed ​​test a year later

image This publication is a continuation of my post last year and a subsequent note . For a whole year, test scripts lay somewhere on the disk. It did not come to comparing JavaScript vs C #, which was suggested after the disgraceful failure of JScript.NET. It didn’t come because I didn’t feel in myself the strength to adequately translate tests with JavaScript, although I actively program in C #. In addition, I made a test run, and it seemed to me that there would be no miracle. Now I decided to put the test package in order, so that everyone can try it out. Maybe someone has the strength to add an adequate comparison with C #.
Under the cut there will be test results a year later, a link to Github, and a new ( old ) way of using the JScript engine from IE9 outside of IE9 itself.



IE9 engine.


')
For a year, IE9 officially managed to exit. Earlier, I thought that after the release, the new JScript engine will replace the old one in the system. So it was with all the engines before. However, after installing the official IE9 found that in the directory C: \ Windows \ System32 there are two libraries - jscript.dll and jscript9.dll.
After installing IE9, Windows Script Host continues to use the old 5.8 engine. The old trick with the substitution of the library name in the registry does not pass. At the same time, the jscript9.dll library is registered with a different GUID in the registry. I already started to lose hope of using the new engine outside of IE, but the solution was still found - you just need to register the GUID jscript9.dll as another Scripting Engine for Windows Active Scripting. I did it with the following * .reg file.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\JavaScript9]

[HKEY_CLASSES_ROOT\JavaScript9\CLSID]
@="{16d51579-a30b-4c8b-a276-0ff4dc41e755}"


Now scripts can be run on the 9th version of JScript from the command line

cscript.exe // E: javascript script.js

Test package



Package posted on Github . To run the tests, except for the package itself, you will need:



To run the tests used a set of simple CMD files. A test session is started by a file.

dotest.cmd

In order to include any engine in testing, simply uncomment the corresponding line in this file.
Each interpreter test is launched by the corresponding run. *. Cmd file, the JScript.NET tests are run by the comp.NET. *. Cmd files. Before running the tests, you must make sure:
  1. that the paths in the required run. *. cmd files correctly indicate the executable files of the engines (if they are not registered in the PATH environment variable)
  2. that the paths in the required comp.NET. *. cmd files indicate the installed versions of the .NET Framework


Each test run creates a new HTML file in a subfolder of results, which is the test result that is almost ready for presentation.

The tests themselves are placed in the tests folder; there you can add your tests, not necessarily to compare the performance of different engines. For example, you can still consider different solutions to the same problem within the same engine. Here is an example test file:
 !function(){ var str1 = 'Hello ', str2 = 'world ', str3 = 'test ', i = 0; tests.push({ name: 'String Concat', func: function(){ i++; return str1+str2+str3+' '+i; }, reduce: function(r,x){ return r+x.length;}, start: 0, loops: 100000 }); }(); 


As you can see, in the tests array you need to add an object with the following properties:


The result of the last test

















Publish the results turned out to be easier in the form of pictures. If someone needs tabular data here is the source file.

What is interesting is that in native tests, the new V8 is much faster than the old one, and in mine a bit slower.
It should also be noted that these tests in no way reflect the advantages of NodeJS in asynchronous I / O. All tests are synchronous and we are testing just different versions of the V8 engine. To test the asynchronous benefits of NodeJS, you need to write special tests. True, in this case it is not clear what else to compare it with in this package. Other engines do not provide similar event loop capabilities.
Well, in the end, as usual, a meaningless rating:



Yes, the hardware is different this year and JScript 5.8 showed clearly better results. However, build 5.8 is slightly different.

Source: https://habr.com/ru/post/134281/


All Articles