pieroxy.net - node.js vs Java nashorn

Re: node.js vs Java nashorn

Mon, 10 Sep 2018 13:17:15 GMT

Both are brilliant Javascript Engines for Java. Unfortunately you can't easily use Node.js packages with Nashorn so you're quite limited. If you are looking for Java Classes in Mumbai then you can Visit Classboat.

Re: node.js vs Java nashorn

Fri, 04 May 2018 13:02:31 GMT

19 ScriptEngines is probably overkill, but having a pool of 5 ScriptEngines might be enough. The point is to reuse them. At most, one per physical core of your server should do the trick. Note that there is most likely a memory footprint for each ScriptEngine so don't create and hold too many of them. As far as optimistic typing is concerned, I'd suggest for you to do a small benchmark to assess the added value of that feature.

Re: node.js vs Java nashorn

Fri, 04 May 2018 11:38:32 GMT

Hi.. thanks for the great article.. We have application which is executing a payload against 19 JS files and each time we are creating the ScriptEngine. Shall we think about going for caching of all 19 JS with 19 ScriptEngine objects? Also I researched on NET but wasnt convinced whether we shall use Optimistic Typing.. We are execute two methods on JavaScript and one is returning Boolean and another String.

Re: node.js vs Java nashorn

Wed, 27 Dec 2017 05:17:21 GMT

Node.js and Java couldn't be much more different in the types of programmers/clients that each attracts.Thanks for sharing.

Re: node.js vs Java nashorn

Wed, 08 Mar 2017 14:35:57 GMT

For the code: To get the ScriptEngine, is not it something like: ScriptEngine engine = engineManager.getEngineByName("nashorn"); rather than ScriptEngine engine = engineManager.getEngineByName("JavaScript");

Re: node.js vs Java nashorn

Sun, 16 Oct 2016 09:29:14 GMT

There are several known ways that node can be tricked into taking a performance hit. Another way is to reassign a variable to a different type. However, like eval, it's not something that you often do in production code, if ever. The V8 performance relies upon assumptions which are sound though not infallible.

Re: node.js vs Java nashorn

Fri, 27 May 2016 09:17:12 GMT

I did test as well, and seems that nashorn is even faster that node, the thing is that jvm initially is slow due some optimization being applied after som few thousands of iterations - i think JIT comes into play. Btw, try code including eval functions and you will see how node becomes slow.

Re: node.js vs Java nashorn

Tue, 05 Jan 2016 18:10:38 GMT

Minification is done in test.js

Re: node.js vs Java nashorn

Tue, 05 Jan 2016 15:32:52 GMT

It looks like it is not minifying the JS code, just executing it in nashorn (basically loading uglify and then loading the test code, but not minifying it).

Re: node.js vs Java nashorn

Sat, 05 Dec 2015 23:00:48 GMT

I know I'm late to the party but I'm betting if you tied the Nashorn test to one core it would probably perform on par with node.js. You're getting bounced between cores which causes a reload of the local cache for the core. That's not efficient, hence why node.js runs in one core. This LMAX Disrupter Thread and core affinity article http://highscalability.com/blog/2015/9/30/strategy-taming-linux-scheduler-jitter-using-cpu-isolation-a.html walks through them trying to isolate their stuff to one core for this exact reason. At the end of the day this repo does all the affinity magic https://github.com/OpenHFT/Java-Thread-Affinity

Re: node.js vs Java nashorn

Sat, 21 Nov 2015 11:35:36 GMT

Not much of a shocker. One thing to remeber with Node.js is that V8 is awesome when it comes to arithmetic operations. Numbers can typically be converted to native ints and all processes have native math instructions. Other JS objects however don't have true native equivalents, and their methods don't have native equivalent instructions, so the whole idea of converting them to machine code is a bit a stretch. Strings are somewhat of an exception because chars are after all just ints, and char/string functions are typically some form of arithmetic. Long story short, V8 is able to crunch numbers (and chars) without fluff, just pure raw machine instructions. Dumping 10,000 strings into a database however will show that node.js isn't always quicker then alternatives.