50K | HackerShow

Skip to content

Languages and libraries

web workers demo

SHOW HN2016

50K

Sorting 50K Array, HTML5 Web Worker Demo

afshinm.github.io

#web workers #javascript #bubble sort #background threads

Shown by afshinmeh on Oct 28, 2016. Click the card to turn it over.

88points

59comments

#432of 2,264 in 2016

Top 20%of 2016 by points

How HN took it

CuriousMostly questions and neutral comments

5 positive, 20 neutral or asking, 1 mixed, 7 critical, out of 33 comments about the project. Thread score -0.04.

Performance: 4 for, 3 againstExecution: 0 for, 2 againstDesign: 0 for, 2 againstIdea: 1 for, 0 against

The thread, comment by comment

Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.

positive neutral or mixed critical about another commenter or something else the maker

What HN said

What people liked

Keeping the UI responsive is worth a small slowdown
From 3 comments
- I must be silly but I expected the web worker version to run faster. I must have understood "many threads". It ran nearly 200ms slower :) That said, not locking the UI thread and…
  keyle on HN
- On Android Chrome the web worker took 18 seconds while the non web worker took 11 seconds but was utterly unresponsive. Having a responsive ui using the web worker with later…
  lai on HN
- The difference on my machine is not even 50ms - good tradeoff for more responsiveness
  nicolasd on HN

Objections

Web worker version is slower than the blocking sort
From 3 comments
- Is this demo supposed to highlight the strength of web worker? It runs 300-400ms slower on web worker.
  didip on HN
- 3.5 seconds on Chrome. Native code does this around 10000% faster.
  sz4kerto on HN
- 2.8 seconds without 3.3 seconds with webworker Imho not acceptable trade-off, did not hear the term web workers yet, and now i'm not even upset i did not and probably will…
  thinkMOAR on HN
Chunking the work with yields avoids needing workers
From 1 comment
- You don't need web workers to be "responsive". You just need to cut the job up into bits, and yield to the UI thread every so often. It's utterly unresponsive because it's not…
  mibbiting on HN

Requests

Use a parallel or merge sort across multiple workers
From 2 comments
- Merge sort?
  laxd on HN
- You can totally split sorting across different threads/cores, just divide the list up and do a final merge pass. Basically the idea behind external sorting, where the amount of…
  OskarS on HN

Questions

Would multiple workers or a better algorithm speed it up?
From 2 comments
- If you wanted to go crazy you can use transferables to get around the memory copy cost. It would be a fun experiment to figure out at what point does it make sense to use…
  chadscira on HN
- > I must be silly but I expected the web worker version to run faster. I must have understood "many threads". They are only using a single worker thread, not multiple, so it will…
  dspillett on HN

Alternatives named

task.js
From 2 comments
- For anyone that is interested in easily using WebWorkers for this sort of work please check out task.js (https://github.com/icodeforlove/task.js). It allows you to send a pure…
  chadscira on HN
- In response to your last comment, you should check out https://github.com/icodeforlove/task.js. It will do that and much more.
  chadscira on HN