Use Web Workers for AJAX requests

Reported by:	andrearo@pvv.ntnu.no	Owned by:
Priority:	low	Milestone:	1.next
Component:	ajax	Version:	1.6.2
Keywords:		Cc:
Blocked by:		Blocking:

Description

Would it be possible to use HTML5 Web Workers to improve the performance of AJAX requests in jQuery?

It seems that Web Workers have access to the XMLHttpRequest object. Running AJAX requests, waiting for a response, and parsing the resulting JSON, in a separate thread will surely improve performance.

It would be nice if jQuery offered Web Worker-enabled AJAX requests as a feature included in jQuery by default.

Attachments (0)

Change History (5)

Changed July 22, 2011 01:58PM UTC by timmywil comment:1

component:	unfiled → ajax
milestone:	None → 1.next
priority:	undecided → low
status:	new → open
version:	git → 1.6.2

We can table this for discussion in a later release since feature requests for 1.7 are closed, but I'm ok with seeing how much code it would take and how much performance would benefit.

Changed July 22, 2011 02:13PM UTC by rwaldron comment:2

resolution:	→ wontfix
status:	open → closed

I've spent a lot of time researching and experimenting with WebWorkers and I can definitively say that this is not a viable or realistic addition to jQuery core.

Changed July 22, 2011 02:24PM UTC by andrearo@pvv.ntnu.no comment:3

rwaldron, could you please elaborate?

Changed July 22, 2011 02:52PM UTC by rwaldron comment:4

_comment0:	This is copied/pasted from -dev channel discussion: \ \ 1. spin up cost of workers is gross \ 2. it would be slower for single ajax requests \ ie. GlobalScope [ postMessage() ] -> WorkerGlobalScope [ onmessage or addEventListener( message ...) ] -> XHR (request) (response) -> postMessage() -> GlobalScope [ onmessage or addEventListener( message ...) ] -> Ajax Handler on client? \ vs... \ XHR (request) (response) \ (current) \ if you had a system that was _polling_ \ eg. open a worker, make xhr requests in a loop forever, on each response, postMessage() the results back to the client \ \ \ 3. We can't create _real_ workers in IE6, 7, 8 and 9 because a real Worker is actually an OS level thread that's capable of being spun up over multiple cores \ \ eg. user A has a quad core, user B has dual core, they both visit a website that makes use of a Renderer (ie. the window) + 2 Workers, so 3 processes in all \ - For A: Core 1: Renderer; Core 2: Worker; Core 3: Worker \ - For B: Core 1: Renderer; Core 2: Worker; Core 1: Worker \ \ so, thats the argument against those bogus "setTimeout" loops pretending to be Workers \ \ \ 4. jQuery will throw dom security exceptions when run in WorkerGlobalScope because `window` and `document` don't exist and jQuery explicitly refers to them → 1311347379245139

_comment0:

This is copied/pasted from -dev channel discussion: \ \ 1. spin up cost of workers is gross \ 2. it would be slower for single ajax requests \ ie. GlobalScope [ postMessage() ] -> WorkerGlobalScope [ onmessage or addEventListener( message ...) ] -> XHR (request) (response) -> postMessage() -> GlobalScope [ onmessage or addEventListener( message ...) ] -> Ajax Handler on client? \ vs... \ XHR (request) (response) \ (current) \ if you had a system that was _polling_ \ eg. open a worker, make xhr requests in a loop forever, on each response, postMessage() the results back to the client \ \ \ 3. We can't create _real_ workers in IE6, 7, 8 and 9 because a real Worker is actually an OS level thread that's capable of being spun up over multiple cores \ \ eg. user A has a quad core, user B has dual core, they both visit a website that makes use of a Renderer (ie. the window) + 2 Workers, so 3 processes in all \ - For A: Core 1: Renderer; Core 2: Worker; Core 3: Worker \ - For B: Core 1: Renderer; Core 2: Worker; Core 1: Worker \ \ so, thats the argument against those bogus "setTimeout" loops pretending to be Workers \ \ \ 4. jQuery will throw dom security exceptions when run in WorkerGlobalScope because `window` and `document` don't exist and jQuery explicitly refers to them → 1311347379245139

This is copied/pasted from -dev channel discussion:

1. spin up cost of workers is gross

2. it would be slower for single ajax requests

ie. GlobalScope [ postMessage() ] -> WorkerGlobalScope [ onmessage or addEventListener( message ...) ] -> XHR (request) (response) -> postMessage() -> GlobalScope [ onmessage or addEventListener( message ...) ] -> Ajax Handler on client?

vs...

XHR (request) (response)

(current)

if you had a system that was _polling_ eg. open a worker, make xhr requests in a loop forever, on each response, postMessage() the results back to the client, then you can benefit

3. We can't create _real_ workers in IE6, 7, 8 and 9 because a real Worker is actually an OS level thread that's capable of being spun up over multiple cores

eg. user A has a quad core, user B has dual core, they both visit a website that makes use of a Renderer (ie. the window) + 2 Workers, so 3 processes in all

For A: Core 1: Renderer; Core 2: Worker; Core 3: Worker
For B: Core 1: Renderer; Core 2: Worker; Core 1: Worker

so, thats the argument against those bogus "setTimeout" loops pretending to be Workers

4. jQuery will throw dom security exceptions when run in WorkerGlobalScope because window and document don't exist and jQuery explicitly refers to them

Changed July 22, 2011 06:01PM UTC by dmethvin comment:5

Yeah, $.ajax is already quite asynchronous since the request and network activity happens in parallel with whatever is going on with JavaScript on the page. All that the web worker buys you is some extra parallelism in the JSON parsing and completion functions, but as rwaldron mentions you wouldn't be able to do any DOM operations there because of the security/thread-access restrictions. For that reason alone it's pretty much a non-starter.

You mentioned it would "surely improve performance", do you have any code examples?

Side navigation

#9889 closed enhancement (wontfix)