Compare embedded JavaScriptCore and Node.js (iojs)

comparison.md

Since an embedded JavaScriptCore can be made to launch quickly, I've been pondering whether it is justified in converting Planck to be a portable (OS X, Linux, Windows) C-based wrapper around JavaScriptCore (so that it is more broadly useful). Right now Planck is not portable owing to the use of Cocoa/Foundation and Objective-C.

I think this partially boils down to wether the launch latency is faster than an equivalent based on Node.js (which is already portable and has a much richer ecosystem). That latency has to be significantly different, and I also think you'd need to be convinced that it is going to remain that way (perhaps V8 will be further optimized, but perhaps the outright launch speed of Node.js isn't a priority).

Here is my first attempt at a comparison, based on Joel Martin's work:

$ time echo '(map inc [1 2 3])' | cljs
cljs.user=> (map inc [1 2 3])
(2 3 4)
cljs.user=> 
real	0m0.826s
user	0m0.748s
sys	0m0.093s

$ time echo '(map inc [1 2 3])' | ~/Projects/planck/build/Release/planck
(2 3 4)

real	0m0.385s
user	0m0.492s
sys	0m0.087s

@bensu Oh, and while you are right, it is approx 1/2 second startup time. But it is out of less than 1 second. I think the ratio is a better comparison. If the numbers above are correct, and your scripting needs are dominated by lots of small scripts that startup and are done, then Planck runs twice as fast.

@mfikes ok got it, you are thinking with Plank (or cljs-repl) as a platform for bash files that call them many times.

Few thoughts:

• You might want to try something slightly more complicated that tests a bit more than just initial startup time, since JSC and V8 seem to do their JITing at different points:

for i in {1..3}; do time echo '(defn foo [a b] (str a b)) (count (reduce foo (range 1 1000)))' | cljs; done

• It's interesting that your planck measures have user time that is greater than real time. That seems to imply that planck is using multiple CPUs
• I think there are some improvements being actively worked for V8 similar to what's in JSC: TurboFan
• We might try and profile both solutions to see where the performance differences stem from. In fact, if we find an area of JavaScript that isn't well covered by the existing major test frameworks, it might be worth proposing an addition to one of them.
• The npm ecosystem is huge (by some measures it is now the largest package ecosystem: http://modulecounts.com). I think supporting that ecosystem well would be a huge selling point (reach). Adding even partial support for the npm ecosystem system via a completely different JavaScript engine and platform would be a major project. At the same time, having relatively easy access to the iOS/OS X ecosystem is also interesting.

So I guess I think there is a probably a place for both. I think having a common core REPL library that is used by all the projects would reduce the effort required to maintain them (maybe eventually incorporated into the ClojureScript REPL related code upstream).

@mfikes yes, the current npm version of cljs uses transit to load the analysis cache (and just embeds it as a JSON string right into the code).

I'm pretty ignorant here. Aren't there more dimensions to consider besides startup time?

C interop in node is not that much fun. Can it be better with javascriptcore?

I guess the bottom line is what niche is planck potentially good at filling. Focusing on os x would be interesting for a big set of people. It might also be a good place to start experimenting with low-level stuff, without immediately taking on the grand yakshave of cross platform.

@kanaka yes, Planck employs a background thread to bring up JavaScriptCore while it does everything else it can until eval is needed.

Perhaps I've been overly focused on startup latency. That has been effectively eliminated for interactive REPL startup (via the background thread) and caching compilation could perhaps do effectively nearly the same for scripts (regardless of Node.js or JavaScriptCore approach). planck-repl/planck#58

If that ends up being the case, then Node is very compelling and will only get better with TurboFan.

Planck has the benefit that it can be shipped as a single binary, this is huge for use as a scripting language runtime.

My 2 cents. Unlike Planck, Node.js isn't designed to be embeddable, it has all the problems of the JVM with respect to that. Further, beyond AWS Lambda, I don't find the Node.js target particularly compelling given the JVM exists for server side applications. I don't even really see an argument for shell-scripting w/ ClojureScript + Node.js, Clojure already has sub-second launch time on modern hardware.

If Planck supported simpler C integration that would be the legitimate killer application. So to me pursuing Windows & Linux should be about broadening embeddability, not trying to achieve Node.js generality (which IMO is an unrealistic goal anyhow).

In summary, Planck has a very compelling niche if doesn't try to replicate what Node.js is already good at.

@kovasb and @swannodette both mentioned C but I'm wondering if they are from different angles.

@kovasb 's comment appeared to be in line with planck-repl/planck#32

But @swannodette 's embedding might be the opposite: You have a native app you'd like to embed some ClojureScript functionality into? Perhaps using Planck as a library?

There's also atom/electron to consider when it comes to wrapping everything up for easy deployment. It's a very different beast, but could be useful to clearly position Planck, I think.

@mfikes iOS and OS X framework inter-op is a huge interest for many Clojure(script) developers.