The main thread is overworked & underpaid (Chrome Dev Summit 2019)

The main thread is overworked & underpaid (Chrome Dev Summit 2019)


Comments

  1. Post
    Author
  2. Post
    Author
  3. Post
    Author
    mehoprelivoda

    pssst, hey kid, chrome dev tools has performance throtling of up to 6x and slow 2g speeds which simulate nokia 3310

  4. Post
    Author
    Galothus

    That's probably why proxx.app does not work on my nokia 8110. Because comlink support for firefox starts with version 52. ( 8110 is firefox 48)

  5. Post
    Author
    Loque

    You demonstrated the impact of screen refresh rate improvements with the impression of performance in ms from the feature phones – which, is probably not important, but just incase you didn't notice it.

    It is more likely that someone with a high refresh rate screen is going to have a more powerful device, but not to take away from the important underlying message that performance is important and we have emerging markets

  6. Post
    Author
  7. Post
    Author
  8. Post
    Author
  9. Post
    Author
    nathnolt

    Why does proxx.app still use a table and DOM nodes despite not being rendered? wouldn't it be better to only use a canvas and handle the events based on x / y positions? Thereby not having the bloat of lots of extra elements, or do some phones not support touch apis? Or is it only on flagship devices where it adds these nodes?

  10. Post
    Author
  11. Post
    Author
  12. Post
    Author
  13. Post
    Author
  14. Post
    Author
  15. Post
    Author
  16. Post
    Author
    shexec32

    Triggered by your use of fake news tactics at 08:26.
    Thy conflate high refresh rates with low cpu performance, to fabricate a malapropos tabule justifying thine 0.007s celeritate terminum minimum JavaScript code.

    You're either going to get a low end phone with a low refresh rate, or a high end phone that's fast enough to run your productive* JavaScript code within 7ms. You won't get a low end phone with a refresh rate requiring over 144fps. Graphs attempting to purport otherwise are misleading at best, Trumpian levels of deceitful at worst.

    Or maybe I'm just triggered by the obsession with 0.016s, where as a citizen of the EU, I'm used to the perfectly acceptable 0.02s standard from PAL. I'll be involuntarily stripped of that citizenship next year, by the only miscreants miseducated enough to understand my second sentence, so maybe I'll have to get used to it.

  17. Post
    Author
    Patrick C.

    Really great video Surma! The lack of easy multi-threading is a severe disadvantage of JS in the coming future, and needs to be fixed. Modern CPUs are getting more cores and threads, with minuscule improvements to clock speed and IPC (for the most part).

  18. Post
    Author
  19. Post
    Author
  20. Post
    Author
  21. Post
    Author
  22. Post
    Author
    Ja mvc

    If somebody can't spend 100$ on budget android phone then why should I care about that person, he/she definitely won't buy my product

    Business is business

  23. Post
    Author
    Vicary A

    I am a random dev desperately waiting for a transparent worker framework to born.

    If the rendering system of React or Angular automatically make use of multiple workers without forcing code changes a new era is promised.

  24. Post
    Author
    Kenji Miwa

    This is an interesting strategy to know about but I suspect for most use cases staying on the main thread might be best for simplicity and speed, especially if most of your users are on powerful phones or desktop.

  25. Post
    Author
  26. Post
    Author
  27. Post
    Author
    deb d

    Pardon my lack of knowledge, but why would a 120Hz screen make 60 updates/sec look bad or sluggish or undesirable? You'd still show 60 updates/sec in a screen that could accommodate 120, but how is that worse than showing it on a 60Hz screen?

  28. Post
    Author
    John Robie

    I feel like a critical piece of the story is missing here. Those minesweeper updates being sent to the UI mean breaking the minesweeper logic into processing chunks, correct? Otherwise, you still have to wait till all the processing is done (even if on another thread/worker). What does that logic look like? How much more complexity are we adding to an application to provide the perception of speed?

  29. Post
    Author
    Quintin Maseyk

    Love it as always! This displays a good summary of all Surma and Jake's videos in regards to this subject. We use a lot of Web Workers for our projects the manual way bundled with Web Pack. Thought we never found the API to be that bad to have to use a library such as Comlink; will look into it more though.

  30. Post
    Author
  31. Post
    Author
  32. Post
    Author
    Shubham Kanodia

    Good talk. Though I doubt web apps are bound by CPU work that can be moved to a worker. Non-DOM /Non-Event CPU work is pretty rare.

  33. Post
    Author
    LuLeBe

    First of all, Surma == most amazing presenter.
    Also, I hope this will become a much more important topic in the future. Because workers are really what could allow extremely complex applications to feel fluid and snappy in the browser. I hope that workers turn into the same thing as threads on other platforms, where they're not an addon, but are even used in the most basic of beginner examples.

  34. Post
    Author
  35. Post
    Author
    Rick Beacham

    The main thread is over worked and underpaid – Maybe we should start a new library named Unionize to help fix these issues…

  36. Post
    Author
  37. Post
    Author
  38. Post
    Author
    Bruno Conde Kind

    Google Chrome Devs speaker using iPhone on benchmark results instead of Pixel reminded me of that MS guy using Edge to download Chrome during an Azure presentation haha

  39. Post
    Author
  40. Post
    Author
    qbert3001

    I realized I'm the main thread at my job.

    You do all the work and people keep giving you more until you're committing 90% of the new code. I need a different job.

  41. Post
    Author
    georgH

    Never block the UI thread. This was extensively put in practice by OS/2 2.0 in the early 90s, and just recently MS Office has managed that most of the time.

  42. Post
    Author
  43. Post
    Author
  44. Post
    Author
  45. Post
    Author
  46. Post
    Author
  47. Post
    Author
  48. Post
    Author
  49. Post
    Author
    Jon Penn

    If I understand you correctly, the goal is just to make sure the browser gets a chance at least once every 60th of a second to render a frame, respond to user input, and run lightweight events. You are accomplishing this by moving preemptable tasks to a separate thread so the os can preempt that browser thread in order to run the main browser thread. I believe you can accomplish the same thing in the style of cooperative multitasking within the main thread with async and await:
    https://jsfiddle.net/evc8y2uk/
    It does run slower with the yeilds, but you could write a more intelligent yeild function to only yeild once every 60th of a second no matter how many times it was called. Then you could just pepper your code with calls to yield. Since you are still in the main thread you can still access everything (dom included) and can share variables (almost) without worrying about mutexes since it is very easy to tell when another piece of code will have the opportunity to interrupt you and change something (it can only happen where you explicitly yeild).
    I believe that this style of safe asynchronous programing is javascript's greatest strength. Admittedly doing things as you suggest makes it harder to accidentally not yeild.

  50. Post
    Author
    Ian

    Surma as I commented on your corner booth video that you responded to. NO I WILL NOT develop for a fox and I will not do it with a proxx I will not develop for poor or stale. I will only develop for chrome 5ghz anywhere. But in all reality the only real answer in a world where speed is not increasing but thread count is JS (ahem V8) will have to abandon the single thread mantra and full wrap it's arms around multi-threaded mindset.

  51. Post
    Author
  52. Post
    Author
  53. Post
    Author
  54. Post
    Author
  55. Post
    Author
    Skip741 x

    chrome on a mac hardly uses the hyperthreads at all, only the main cores…in windows, all cores and threads are used equally

  56. Post
    Author
  57. Post
    Author
  58. Post
    Author
  59. Post
    Author
    Chad Scira

    I made Task.js to make working with workers a little easier ( https://github.com/icodeforlove/task.js ). Also supports node.js, and worker_threads.

  60. Post
    Author
    Johnny Deep

    When he started discussing hertz he lost me, why would the hz of a monitor decrease the deadline like that? The amount of time it takes and the impact on the customer is exactly the same regardless of whether your monitor's got 60hz or 5000hz

Leave a Reply

Your email address will not be published. Required fields are marked *