I'm currently playing with the idea of using IFRAMEs to implement a very simple multithreading engine. However my initial results are showing me that running in threads is slower than just running in a single thread.

My test is:

Single Thread

var start = new Date().getTime();
for (var i = 0; i < 300; i++) { /* Do costly processor operations */ }
debug('Took: ' + new Date().getTime() - start);

Multiple Threads

var start = new Date().getTime();
// In thread 1
for (var i = 0; i < 100; i++) { /* Do costly processor operations */ }
// In thread 2
for (var i = 100; i < 200; i++) { /* Do costly processor operations */ }
// In thread 3
for (var i = 200; i < 300; i++) { /* Do costly processor operations */ }
// In a callback in the original FRAME (thread)
debug('Took: ' + new Date().getTime() - start);

So as can be seen, I'm just splitting the work load amongst IFRAMEs (Note code above is only to give a better picture of what I am doing, it is not working code).

So I'm thinking that even using FRAMEs FireFox still has only one JS engine? Is this assumption correct? (rendering my research stupid), Are other browsers different?

Doing a quick googles I got this article: .html

However the performance improvements achieved here are more than likely just doing parallel http requests rather than processing power.

Thanks for your insights.

Guido

I'm currently playing with the idea of using IFRAMEs to implement a very simple multithreading engine. However my initial results are showing me that running in threads is slower than just running in a single thread.

My test is:

Single Thread

var start = new Date().getTime();
for (var i = 0; i < 300; i++) { /* Do costly processor operations */ }
debug('Took: ' + new Date().getTime() - start);

Multiple Threads

var start = new Date().getTime();
// In thread 1
for (var i = 0; i < 100; i++) { /* Do costly processor operations */ }
// In thread 2
for (var i = 100; i < 200; i++) { /* Do costly processor operations */ }
// In thread 3
for (var i = 200; i < 300; i++) { /* Do costly processor operations */ }
// In a callback in the original FRAME (thread)
debug('Took: ' + new Date().getTime() - start);

So as can be seen, I'm just splitting the work load amongst IFRAMEs (Note code above is only to give a better picture of what I am doing, it is not working code).

So I'm thinking that even using FRAMEs FireFox still has only one JS engine? Is this assumption correct? (rendering my research stupid), Are other browsers different?

Doing a quick googles I got this article: http://codediaries.blogspot./2009/12/real-javascript-multithreading-using.html

However the performance improvements achieved here are more than likely just doing parallel http requests rather than processing power.

Thanks for your insights.

Guido

• javascript
• multithreading

• How about you add some zeroes to the loop counter? Make it 10000, 20000 and 30000 respectively and see what happens. – chakrit Commented Dec 31, 2009 at 2:58
• chakrit: My real tests are using 1000s of iterations, the example above is small just for simplicity. – gatapia Commented Dec 31, 2009 at 3:02
• One thing to make sure you also take into account is JavaScript timer resolution, which is often 15ms: ejohn/blog/accuracy-of-javascript-time – Annie Commented Dec 31, 2009 at 3:04
• 1 Even if distributing putation to multiple iframes would work as real multi-threading, wouldn't the overhead necessary to run five such engines render naught any possible gain in performance? – Pekka Commented Dec 31, 2009 at 3:34
• What is it you're doing that even requires multithreading? – Breton Commented Dec 31, 2009 at 3:54

5 Answers 5

Check out the HTML5 Web Workers Standard to see what JavaScript threading should look like. This is implemented in Firefox 3.5, Safari 4, and Chrome 3, but not IE. If you're willing to require a plugin for IE users and older browsers, check out Google Gears WorkerPool.

No, Javascript generally does not support multi-threading. Most interpreters do not have any multi-threading capabilities built-in (just like PHP), probably for portability reasons.

However, since the Rhino engine is written entirely in Java, you may be able to tap into the Thread class, but this would only be feasible if you are doing server-side Javascript.

I've decided on a browser dependant solution. Basically I will use Workers if available, then Gears if available. Finally just single threaded.

Thanks all

Guido

setTimeout call might be a good solution in some circumstances.

It depends what you call a thread. No, this isn't going to spread any load out to other cores, but it IS multithreading in that the thread for the process gets given up to another process in the code. Split your heavy cycles into chunks and it you will let the rendering engine and other events get a look in.

You could try wrapping your operations in a setTimeout call.