6 ms·

Although the web worker version is slower, the fact that it doesn't block UI is a huge gain. I tried to see if I could make the bubble sort function async as t

Although the web worker version is slower, the fact that it doesn't block UI is a huge gain. I tried to see if I could make the bubble sort function async as to not block the browser UI using callbacks as opposed to workers. Here's a (messy) fiddle for those that want to check it out: https://jsfiddle.net/tbinetruy/8q1de9jk/ https://jsfiddle.net/tbinetruy/8q1de9jk/ (watch out, this fiddle runs the blocking bubble sort on a 50k array on page load, so it'll freeze your UI for 5 seconds. Then the non-blocking sort kicks in and your UI becomes usable again). For a 50k array, the blocking code ran in 6.682s and the non-blocking code in 9.297s (when I ran it locally just now anyway). I added a clickable button and update the DOM every 25ms with a random number to show the user what the non blocking code allows for. The same type of non blocking code without relying on web workers should also be possible with async functions and promises. I'll have to look into it.

methyl 10y ago
To me, it's not slower, performance almost exactly matches the blocking version. I'm on i7 Macbook Pro and Chrome.
chadscira 10y ago
In response to your last comment, you should check out https://github.com/icodeforlove/task.js https://github.com/icodeforlove/task.js. It will do that and much more.
fenomas 10y ago
I don't get why everyone is focused on the worker version being slower. Microbenchmarks in JS are hard to get right, and I don't think this demo attempts to make an accurate comparison. It's just showing what workers do and why they're useful. I use workers heavily in a game I'm making, and in my experience they perform equivalently to regular JS, modulo any time you spend copying memory back and forth. edit: It seems this demo dynamically creates the worker from scratch every time it's used, and destroys it afterwards. That's probably the cause of any performance difference people are seeing.
- chadscira 10y ago
  Good catch. From my experience though there is a small overhead in terms of workers, also the message cost. But still even if it was 300% slower it's justified because it is unacceptable to lock the browser. Too many commenters here are coming from the backend, or desktop software where they already have a UI thread. I ask these commenters a simple question, when is the last time you saw your browser freeze? If that doesn't happen often then the devs are doing many things like this to keep that experience enjoyable. Web is it own kind of beast in terms of development, the biggest concern is perceived responsiveness. We get to write off async delays when using webworkers (and similar methods) because users are already used to network requests taking time.

methyl 10y ago

To me, it's not slower, performance almost exactly matches the blocking version. I'm on i7 Macbook Pro and Chrome.

chadscira 10y ago

In response to your last comment, you should check out https://github.com/icodeforlove/task.js https://github.com/icodeforlove/task.js. It will do that and much more.

fenomas 10y ago

I don't get why everyone is focused on the worker version being slower. Microbenchmarks in JS are hard to get right, and I don't think this demo attempts to make an accurate comparison. It's just showing what workers do and why they're useful. I use workers heavily in a game I'm making, and in my experience they perform equivalently to regular JS, modulo any time you spend copying memory back and forth. edit: It seems this demo dynamically creates the worker from scratch every time it's used, and destroys it afterwards. That's probably the cause of any performance difference people are seeing.

chadscira 10y ago
Good catch. From my experience though there is a small overhead in terms of workers, also the message cost. But still even if it was 300% slower it's justified because it is unacceptable to lock the browser. Too many commenters here are coming from the backend, or desktop software where they already have a UI thread. I ask these commenters a simple question, when is the last time you saw your browser freeze? If that doesn't happen often then the devs are doing many things like this to keep that experience enjoyable. Web is it own kind of beast in terms of development, the biggest concern is perceived responsiveness. We get to write off async delays when using webworkers (and similar methods) because users are already used to network requests taking time.