Web browsers are limiting the benefits of multi-core CPUs.
When it comes to purchasing consumer-grade PCs these days, it’s rare to find a system with a CPU that only has a single core. Most laptops even offer a dual-core CPU. So as software developers, we’re entering a unique era where we can start to employ parallelism in ways that would not have been practical before. In some cases, we will need to exploit this parallelism if we hope to increase the performance of our software.
Unfortunately, we are also seeing a move towards the development and use of Web-based applications. These are applications that are hosted on a remote server, and provide an HTML- and AJAX-based interface that is accessed via a Web browser.
These Web browsers attempt to give us some degree of parallelism, often through tabbed browsing. While this works great for relatively static content, we experience problems with JavaScript scripts that run for anything longer than 500 ms or so. Since the computation of all of the tabs is performed within the same (main) thread of the browser, a long-running JavaScript script immediately locks up all of the other tabs.
The solution is quite clear: each browser tab should have its own thread, in which a separate instance of a JavaScript interpreter executes. A long-running JavaScript script in one tab (ie. one that runs for 2 to 3 seconds, if not more) will not prevent, at the very least, the user from switching to an alternate tab and continuing to work there.
Of course, most Web browsers today just aren’t prepared for such an architectural change. And considering how large of a job it is to write a high-quality browser, it seems unlikely that we’ll see a Web browser written from the ground up that better supports the benefits offered by the now-prevalent multi-core CPUs. So it’s quite unfortunate that we have all of this processing power available to us, but it can only be exploited to a limited degree because developers are choosing to write JavaScript-based applications that execute within parallelism-unfriendly Web browsers.
December 10th, 2007 at 1:32 pm
Actually, it seems IE7 does just this: thread-per-tab. See Bruce Morgans comments in the link below:
http://adamstiles.com/2005/05/ie7_tabs_to_gor/
December 10th, 2007 at 2:00 pm
Very interesting observation! It can’t be that difficult, can it? I would tinker with some open source browsers and do some kind of benchmark. If I only had the time…
December 10th, 2007 at 3:28 pm
Yea, it’s stupid. Even on one core the benefit of separate threads for each tab would be wonderful. No more freezing one website to serve the ads of another. FWIW, tabs are also a bad idea. Tab functionality belongs in the window manager. The window manager should be programmed to open either in a tab or a new window depending on the application.
December 10th, 2007 at 3:31 pm
Maybe we should go back to developing desktop applications. I enjoy that much more than web.
December 10th, 2007 at 3:43 pm
My first concern is what parallel processing of javascript will mean for web developers from a debugging point of view. From a native software development point of view, debugging multi-threaded apps is complicated enough. What will this mean for javascript debugging? Or will it make javascript safter in the sense that a buggy script won’t bring down the entire browser session?
Suppose a script gets locked in an infinite loop, if it’s executed on a lower priority thread with the main thread still in control, we could safely kill the script. Sounds good on paper but this will be a burden either on the browser developer or the web developer.
Plus, the idea of loading an entire JS interpreter in a each tab as a separate thread puts a lot of memory overhead, and people are already complaining about Firefox consuming too much memory…
December 10th, 2007 at 3:45 pm
huh ?
I’ll admit it took a few months to migrate to tabbed based browsing. Personally, each window is a topic, and each tab becomes a thread in that topic while working.
Just open another window and you have another thread.
Now, a post on why Windows sucks SO BAD on this workflow issue, when compared side by side to Ubuntu - That’s an article I’d like to see. Actually how about 10 of them.
December 10th, 2007 at 4:42 pm
Congratulations on a well written article that is not ultra-techy in style. I think this is an important consideration if you want this issue to gain momentum.
I totally agree with your suggestion to run separate instances of JavaScript for each tab. All too often I have had my browser (Firefox is my current fave) crash due to Javascript problems in just one tab. Not to mention the loading/refresh of a page being frozen by one unruly tab which devours all the available JavaScript processing capability.
There is a version of IE7 that is built for x64 but I have no idea if it implements separate JavaScript interpreters. Anyone have any idea? I would imagine not.
So come on Firefox dev community. You heard the call, now is the time to steal a march not only on IE (once again) but on all the browsers out there. We want multi-threaded Firefox.
PS. Found your blog via a Reddit link in case you are interested.
December 10th, 2007 at 4:55 pm
I thought your blog was great and I posted a link to it in my latest blog:
http://buildingtheweb.blogspot.com/2007/12/it-is-time-to-take-www-behind-shed-and.html
December 10th, 2007 at 5:00 pm
Just had to comment when I noticed that the “Security Word” to leave a comment was LMAO.
December 10th, 2007 at 5:13 pm
Of course, the other side of this coin is that a single-threaded web browser can’t hog a multi-core CPU and bring an entire PC to its knees, no matter how many annoying Flash ads are running, no matter how much poorly-written JavaScript is limping along.
I would regard that as a sort of unintended benefit. I’ve recently upgraded my single-core PC to a dual-core system. I had not expected the web-browsing experience to change much, but I think it has.
December 10th, 2007 at 5:37 pm
One way to mitigate this (from the end users perspective) is to use Prism (http://labs.mozilla.com/2007/10/prism/) to convert heavy duty web apps into pseudo-applications.
I use Prism to keep GMail open - GMail’s heavy use of Javascript etc isn’t than stalling my web browsing in Firefox and crashes, freezes, etc in Firefox won’t affect my ability to scan my mail…
December 10th, 2007 at 6:43 pm
http://labs.mozilla.com/2007/10/prism/
It would be simple to work backwards from here to browser tabs per prism app.
December 10th, 2007 at 7:10 pm
While this idea is good, any reference to multi-core processors in relation is bogus. Infact, there is a very good chance that on a multi-core system, all of the threads for the web browser application will execute on only ONE of the system cores, reguardless of the inner architecture.
The actual responsiveness would increase in this scenario but I would imagine that memory consumption would increase as well as mentioned in the article, the complexity would go through the roof.
December 10th, 2007 at 7:13 pm
Perhaps Opera, that browser that nobody seems to care about will come up with a new approach and actually put the competition to shame (they are actually already pretty good, just ignored in the industry for some odd reason).
December 10th, 2007 at 7:26 pm
Bullshit. Even one single core in 2007 should be more than enough to render HTML and run fairly complex JavaScript. Has always been.
What kind of scripts are you talking about when you mention 2-3 seconds? What do those pages do and where did you find them? In reality, you are always waiting on one of the following things:
1. HTTP requests
2. Slow and power hungry flash plug-in
3. Installed extensions: toolbars, javascript debuggers, greasemonkey, etc
#2 is getting worse and worse because of misuse of a certain function call commonly known as “AJAX”. Threads will not help. Threads rarely help on desktop: you always need just two: one for UI, one for IO.
December 10th, 2007 at 7:28 pm
Why not just run multiple instances of a web browser?
December 10th, 2007 at 7:47 pm
I love using Prism / wiki.mozilla.org/WebRunner
Not the same but stable use of web apps.
Good article.
December 10th, 2007 at 8:12 pm
This idea - that each browser tab should have its own process - or for that matter that every field you might type in or interact with should have its own process - is a poor one, only in that it is obviously correct and practical. Software is supposed to be a matter of muck and mire. Thoughtful, efficient code is for sissies.
Personally, when I load 9 tabs at once and my browser locks up because one of the tabs need 384 seconds to load (mostly doubleclick and google ads), I look upon it as a chance to take out my stonecutting tools and craft a quick message.
In 1981 I had a personal computer with a 5MHz processor. It very easily kept up with my typing - I laughed, knowing only the Sorcerer’s Apprentice could even hope to keep with this wizard of a machine. I could switch focus between documents instantly.
Now, with a processor 500 times faster, I can easily out-type my computer. My fingers know what I’m writing, but the letters only appear on-screen after a sickly delay. Maybe they are being transmitted via the NSA, Mossad, Mars, Mossad, and Venus and then back again. My computer is brand new, but it’s a 90-year-old that shuffles.
With enough progress, in 10 years we will be running a PetaHertz computer which will take 11 hours to boot up and then 2.5 hours to type the letter “a” (uppercase will take longer).
Of course the important things will be handled. We will be truly safe from terrorism. The letter “b” (upper and lower case both) will be a thought crime. Your computer will Taser you and all your children with PetaHertz efficiency for initiating the thought to type a “b”.
You just can’t stop progress.
December 10th, 2007 at 8:14 pm
I think there are two separate issues here. The first is that some Javascript applications lock up the Javascript interpreter for 2-3 seconds. I would consider any such application to be buggy — even if you could switch to other tabs, *your* app would still be completely unresponsive to user input, which is definitely a usability problem. Large computational tasks can and should be broken up to yield control back to the UI code and Javascript engine so that clicks and keystrokes can be processed (at least so that you have a usable “Cancel” button).
The other issue here is that a single-threaded browser doesn’t take advantage of multiple cores for computation. This may be a problem in the future, but I haven’t yet seen a Javascript app which had any business soak up enough CPU that multiple cores would have helped performance.
That said, a multi-threaded browser is an excellent idea if only in order to not lock up the whole thing when one tab loads some misbehaving Javscript. For what it’s worth, I believe that Safari is already multi-threaded.
December 10th, 2007 at 9:10 pm
Internet Explorer 7 uses a separate thread for each tab (and can reach 100% CPU usage with 2-4 tabs opened at once).
Firefox and Opera do not. Safari is so fast on my PC that it is hard to test.
The newest Flash 9 uses multiple cores for some rendering. It can reach 100% CPU on certain sites.
December 10th, 2007 at 9:43 pm
How is this issue related to multi core cpu’s? Single core processors also do threading..
Also, javascripts running for 500ms are wrong anyway; real processing should be done server side since I only look at one page at a time and I’d like that page to be fast. In case of malformed sites firefox fixes the issue by allowing me to abort the script, so I think your article is missing the port.
December 10th, 2007 at 10:21 pm
Per tab as a first step maybe. The entire page really should be multi-threaded. The GUI MUST be separated from the rendering processes. It’s happened so many times that a page renders incorrectly or a runaway Javascript application becomes a CPU hog and the main interface stops responding.
December 10th, 2007 at 10:27 pm
Hi, a little off-topic, but you should really change your captcha format. Use Re-Captcha, it’s much better, plus it helps translate books. The captcha you use is trivial for computers to solve.
December 10th, 2007 at 10:33 pm
Provide evidence for your claims, data and analysis.
Talk about it with some of the mozilla developers.
>> The solution is quite clear
Is that so? Did you just start learning about parallelism or something?
December 10th, 2007 at 10:48 pm
It seriously doubt that each browser tab should have its own thread. It would be too many threads. Three of them should ease the pain enough.
One solution is to use Lazy Loading, freezing is usally caused by long loops, thoose loops will go from start to end no matter what, and nothing can run aside them. By using Lazy you actually cut long loops into smaller ones, and you’re adding delay between them, so another part of the application can take the control.
December 11th, 2007 at 1:24 am
This is so true. It’s beyond frustrating when I’m browsing the web on my linux box (Ubuntu 7.10, Athlon 3800×2, 2Gb DDR and 10k SCSI HD) which should rip through most applications fine and does but hit a website with alot of flash or javascript? Watch the system…just…start…to……die.
Its insane that we have browsers that aren’t multi-threaded really at all.
December 11th, 2007 at 4:42 pm
A thread per tab is both: a better solution than executing all tabs in a single thread, and, not nearly enough to improve the current browser problem. Browsers either have to be the most difficult programs to develop, or just the realm for the worst programming of our day. My computer can handle a high-detail, dynamic 3D game with many other players on the screen, particle effects, etc., I can run multiple applications at the same time such as a raster editor, vector editor, spreadsheet app, etc., but once I have 10 tabs open in my web browser with nothing else loaded and a heavy web app like Gmail starts throwing errors or executing large loops, everything comes to a halt.
Maybe it’s just my fault for depending on Firefox so much, which is memory hungry and full of memory leaks. The point is, *something* needs to be done about the way browsers are developed, because they clearly are not taking advantage of present hardware and they are not handling these popular runtimes (JS, Flash, etc) well enough.
December 12th, 2007 at 9:10 pm
“So it? quite unfortunate that we have all of this processing power available to us, but it can only be exploited to a limited degree because developers are choosing to write JavaScript-based applications that execute within parallelism-unfriendly Web browsers.”
it’s always easier to blame those damn goofy developers to choose to work on a technology that is demanded from the market and has lots of advantages as well as the same amount of problems that any other non-web app can have.
December 18th, 2007 at 11:05 pm
SO MUCH BALONEY HERE!
Of *COURSE* threads-per-tab is better!
I’m watching, right now, a dual-Xeon machine that shows up under Ubuntu as having 4 processors because of Hyperthreading, running Gutsy and the latest Firefox, where the machine is AT LEAST 50% idle, ONLY because of the stupid single threaded browser architecture! If I have 8 tabs open, and 3 of them have 500 ads, stupid plugins, badly written frequently refreshing Flash crap, etc., well, if the OPERATING SYSTEM could balance the resources, then the NICE tabs could still be responsive! It is STUPID STUPID STUPID to criticize the BAD PAGES, or that web pages “”"SHOULDN’T”"” be like that! THEY ARE, THEY WILL CONTINUE TO BE, THEY’RE HERE, THEY SUCK, GET USED TO IT! If I find a browser that will do a thread per tab with no stupid cross dependencies, I’LL DROP FIREFOX IN A NEW YORK MINUTE FOR IT! Damn, we got idiots on this thread saying that 3 threads should be enough, and other idiots saying that threads don’t help desktop apps, or worry about debugging getting harder (JOIN THE 1990s!), people worried about the memory cost (HEARD OF SHARED MEMORY and COPY-ON-WRITE?), someone saying that when a tab locks up their whole browser, they get out their quill and notify the maintainer of the offending site, some IDIOT thinking that on a “desktop” you just need one thread for IO and one for UI (that is fine, PER APP or PER TAB! O-K, I’ll grant you all, we need 3 or 4 threads per tab, not just 1… PER TAB).
JEEZUZ, it has been a while since a thread irritated me this much! All because I searched for “multi-threaded browser” in frustration.
December 21st, 2007 at 6:50 pm
Look, it is very hard to sound polite commenting on this post. Web browsers do not NEED multi-core CPUs. In fact web browsers must not even consume more than 1% of a single core CPU, because they are what they are - freaking browsers.
I do not want browsers to introduce “parallelism” - it will be one more excuse for dumb-ass web-”developers” to produce sacks of useless JavaScript loops that consume my computing power while I am trying to read news or purchase a movie ticket.
Pentium III 800Mz used to be a powerhouse 5 years ago and it was more than enough for web surfing. Guess what? Nothing has changed in Web technology since then - same download speeds, same HTML, same CSS, same JavaScript. Why are you preaching for multi-core CPUs?
December 26th, 2007 at 1:13 am
The worst offenders seem to be wordpress plugins.
It’s bad enough to go to a blog and find just a tiny snippet quoting some other blog as it’s entire content.
It’s worse when the blog uses wordpress plugins that lock up the browser. Of course, this happens while browsing the sixth page of search results requiring the user to end task the browser and then try to find the search term again.
Recently I went through the exercise of banning all offsite javascript content by using the hosts file while looking at a particular wordpress blog using plugins. No, it wasn’t the two hit counter scripts, or the three ad servers. It was a wordpress plugin hosted on the same server. Once the plugin was blocked, no more lockups. If it had been the third party servers, it would have been easy to ban them, but since wordpress plugins are normally hosted on the same server, it would require disabling javascript globally.
Javascript developers: please test on all browsers, because your users won’t!