Is it possible to run JavaScript code in parallel in the browser? I'm willing to sacrifice some browser support (IE, Opera, anything else) to gain some edge here.
+5
A:
If you don't have to manipulate the dom, you could use webworkers ... there's a few other restrictions but check it out @ http://ejohn.org/blog/web-workers/
JKirchartz
2010-10-09 19:58:42
Hmmm. Looks perfect though I'm interacting with a `canvas` element. Probably won't work with that, am I correct?
Josh K
2010-10-09 19:59:59
I believe updating a canvas node is the same as interacting with the DOM. But it never hurts to test.
Justin Johnson
2010-10-09 20:01:16
You can use your web-workers to send control messages that are then interpreted to change the DOM, there's just no direct access.
JKirchartz
2010-10-09 20:16:34
Can you give me a list of browsers this works on?
Josh K
2010-10-09 20:22:19
Firefox 3.5+, Safari 4+, Chrome 4+ support it...
JKirchartz
2010-10-10 12:14:58
Webworks forks by executing **new Worker("worker.js");**, which loads the new script and runs it. That's a pretty high overhead fork. The computation better be a *lot* of work to make this worth it. (The examples given on the link are things like "ray tracing", which are a lot of work).
Ira Baxter
2010-10-15 22:08:02
A:
Perhaps it would be better to recode your JavaScript in something that generally runs faster, rather than trying to speed up the Javascript by going parallel. (I expect you'll find the cost of forking parallel JavaScript activities is pretty high, too, and that may well wipe out any possible parallel gain; this is common problem with parallel programming).
Javascript is interpreted in most browsers IIRC, and it is dynamic on top of it which means it, well, runs slowly.
I'm under the impression you can write Java code and run it under browser plugins. Java is type safe and JIT compiles to machine code. I'd expect that any big computation done in Javascript would run a lot faster in Java. I'm not specifically suggesting Java; any compiled language for which you can get a plug in would do.
As an alternative, Google provides Closure, a JavaScript compiler. It is claimed to be a compiler, but looks like an optimizer to me and I don't know much it "optimizes". But, perhaps you can use that. I'd expect the Closure compiler to be built into Chrome (but I don't know for a fact) and maybe just running Chrome would get your JavaScript compiler "for free".
EDIT: After reading about what about Closure does, as compiler guy I'm not much impressed. It looks like much of the emphasis is on reducing code size which minimizes download time but not necessarily performance. The one good thing they do in function inlining. I doubt that will help as much as switching to a truly compiled langauge.
EDIT2: Apparantly the "Closure" compiler is different than the engine than runs JavaScript in Chrome. I'm told, but don't know this for a fact, that the Chrome engine has a real compiler.
Ira Baxter
2010-10-15 17:59:33
It compiles JavaScript into JavaScript, optimizing along the way (inlining functions, etc.). See [the FAQs](http://code.google.com/closure/compiler/faq.html#how-different). I'm concerned that you're making huge assumptions about how JavaScript performance compares to Java — for instance, WebKit's JavaScript engine uses a JIT compiler — and whether Java is appropriate for the OP's use case.
Sidnicious
2010-10-15 18:53:50
Java does *not* run faster in a browser then JavaScript. Not only is it slow and clunky to code in (for a web application) but you are severely limiting the interaction with the DOM unless the entire page is an applet. Any big computation *could* be done in Java, however I don't have any really big computations. I would like to parallel an operation on a [pet project I am working on](http://joshuakehn.com/blog/static/sort.html) the goal of which is to have no need for a browser plugin or other external lib.
Josh K
2010-10-15 19:08:55
@Sidnicious: yes, I figured out it was JavaScript -> JavaScript, which I why I called it an "optimizer". I did suggest that a real compiler existed (perhaps under Chrome); glad to hear there's another from WebKit. Having said that, Java's data model and accesses IMHO are closer to real machines than JavaScript and I'd be pretty surprised if effectively identical computations compiled by Java JITs with Sun's/IBM's team ran slower than Webkit's or any other "compiled" JavaScript. OP didn't specify what he was doing, only that it was slow, and one assumes as a default that is computation.
Ira Baxter
2010-10-15 20:14:30
@Josh K: If you don't have any really big computations, you're going to have a hard time running them in parallel, as forking overhead may dominate the parallel execution time. I understand DOM access might be slower from Java (er, the browser doesn't offer a DOM interface to Java?); if you want parallel access to the DOM you may have a whole new set of problems related to data races and atomicity. Since you didn't specify what you were doing in advance, what you got was generic advice.
Ira Baxter
2010-10-15 20:17:28
@Josh K: ... cute project at your link ... I still don't know what you are you are doing that requires parallelism here, since this appears to be something that is designed to operate at people speeds.
Ira Baxter
2010-10-15 20:23:58
@Ira: I'm very sure Java is sandboxed into it's own playground. This is designed to operate at slower speeds, but if I could thread some of the more intensive algorithms (bubble sort tends to freeze) I believe I could have it perform better.
Josh K
2010-10-15 21:29:21
@Josh K: It may be sandboxed. While it might turn out to be slower for silly reasons, why would a sandbox be " *designed* to operate at lower speeds"? I suggest you code your bubblesort in JavaScript, and again in Java, and compare execution times to get an idea of what the speed differential *might* be. I'll agree, your bubble sort demo runs rather slowly, but I don't know the exact cause; bubblesorting 20-30 odd items finishes on most compiled programs I've written in milliseconds; it is an O(N^2) algorithm but O(1000) just isn't that long.
Ira Baxter
2010-10-15 22:00:35
@Ira: The length of time is because it redraws the array every step. Also with ~240 elements (large set) = ~57k redraws that are pushed into an interval queue before being rendered. I understand the speed difference, however I'm trying to make this mobile friendly and Applets just don't play well there.
Josh K
2010-10-15 23:56:32