6 ms·

I did all the tests faster without webworkers than with them.

• theCricketer 11y ago
  I think the purpose was just to show that you can perform the computation without stalling the rendering thread, not that it is faster.
  • afshinmeh 11y ago
    Exactly. It's not necessarily faster. The point is, I wanted to show that a cpu-bound task like sorting can be done in web browser without experiencing interrupts or hiccups.
• onion2k 11y ago
  They're not faster. They take roughly the same amount of time, but with an extra bit of overhead for instantiating the worker and an event to say it's finished, so they're actually slower. But.. they don't block the browser doing things so the page still responses to input while they're working. If you need to do something that's doing to take 8s (e.g. this demo on my Mac Air), having the user still able to interact with the page while a progress bar updates is a huge advantage.
  • afshinmeh 11y ago
    Nice explanation.
  • eueueu 11y ago
    It's trivial to periodically pass control back to the UI with setTimeout or setInterval. So doing something that takes 8s doesn't have to block the UI at all. The "without webworkers" version should be renamed to "Naively programmed version" or something.
    • tedunangst 11y ago
      Does that work?
      • eueueu 11y ago
        Yes it does. I'm not convinced multithreading is something that should be encouraged within javascript personally.
    • magicalist 11y ago
      It gets ugly fast. Most tasks are not a simple sort. There's a reason that cooperative multitasking is not widely used in operating systems anymore.
      • eueueu 11y ago
        Javascript is not an operating system. There aren't many operations in javascript which will block. The only real issue is that your javascript code executes in the same thread as UI. Which just means you need to think a bit harder about keeping it responsive. "Start threads!" in programming is usually a lazy hack.
        • LnxPrgr3 11y ago
          Lazy hack, or using OS/browser/whatever features instead of reinventing them poorly? What's the benefit you get from programming like that?
          • eueueu 11y ago
            Because once you introduce threads, your program complexity increases massively. You're now throwing a few groups of instructions at the CPU and saying "Hay! Execute these instructions in any order you like". Then you're adding code to deal with the issues of that random execution entails. Also, it's not faster, so what's the actual point? The browser should use all CPU cores efficiently to make javascript fast. Exposing WebWorkers to javascript programmers IMHO is totally the wrong way to do that.
• Ravengenocide 11y ago
  > Your browser sorted 50K Array without any crash or lagging, because your browser supports Web Worker. When you do a job with Web Worker, it's just like when you run a program in another thread. Also you can see the animated progress bar while sorting. The text clearly explains that it's about not lagging or crashing, not about being faster.