Re: WG Design call - May 2nd 10am PST

Hey all,

The minutes
<https://docs.google.com/document/d/e/2PACX-1vQauZtd0BbuU1KiSd8hrL5uIO9qmT5BjtTO7IoR6WuFT_vsMNNzzK0_T81aY0T_sk4-DxND4UaugQhb/pub>
and video <https://youtu.be/Gku1iNQYGQM> from the call are now available.
Copying here for safe keeping.

Cheers :)
Yoav

WebPerfWG design call - May 2nd 2019
Participants

Will Hawkins, Emily Hanley, Tim Dresser, Nicolas Pena, Gilles Dubusc,
Philippe Le Hegaret, Shubhie Panicker, Ryosuke Niwa, Benjamin De Kosnik,
Steven Bougon, Ilya Grigorik, Todd Reifsteck, Andrew Comminos, Nic Jansma,
Scott Haseley, Markus Stange, Shweta Joshi

Chair: Yoav Weiss

Next call: 16th May 11am PST

AI: Yoav to send notification to the list on the F2F

Main Thread Scheduling
<https://www.google.com/url?q=https://docs.google.com/presentation/d/13WXMne_wccp-GRoAKIzGyyILFV95P-29mZ4OiYVeeso/edit?usp%3Dsharing&sa=D&ust=1557326850419000>
(Scott
Haseley)

Native scheduling API - wanted to update the group.

   - Scott: presenting


   - Motivation


   - Userspace schedulers are limited to framework, app or userspace


   - Native scheduler will be able to schedule multiple unrelated entities
   - shared notion of priority
   - Current web scheduling model: input, then rendering, then everything
   else, then idle


   - Everything else is not well-scheduled, one big FIFO


   - Rniwa: this model works for blink, but webkit doesn’t prioritize input
   - Scott: do you actually prioritize different things?
   - Shubhie: probably less prioritization in webkit. Let’s talk more after
   the presentation.
   - Scott: have different task queues, but for a single document, it’s a
   single task queue


   - React scheduler prioritizes specific tasks, but only meaningful in the
   context of react. The browser is not aware of them
   - The MVP plans to resolve that problem.
   - Other problems: no unified API, when to schedule frames, clean reads
   (maybe requestPostAnimationFrame solves that)
   - Requirements - unified priorities, above and below the default,
   separation of API priorities from internal priorities
   - Propose new priorities: 8 new levels: immediate, input events,
   rendering, input, high, default, low, Idle
   - React e.g. wants to yield to input, but maybe not immediately
   - What do we want to prioritize? Userscript tasks, events, script
   parsing, etc. Most beyond scope.
   - Static or dynamic priority system? Maps uses static, React dynamic
   - Browser control? Priorities system? Could go with shared priority
   queues or isolated ones
   - Proposal: start simple. Single set of priorities. Different apps have
   different requirements and dynamic seems more complex and may not be
   needed. Also plans to start with unified set of task queues.
   - Plan to publish explainer, implement and experiment with, and have
   partners play with
   - Invite all to comment.


   - Shubhie: Just creating a postTask based API is probably insufficient.
   So plan to push more API and integrate script and fetch tags


   - Most important is hearing what kind of validation people want to see.


   - Ryosuke: From our side, unclear what user facing issues are we trying
   to solve
   - Shubhie: it’s mostly about juggling priorities and deadlines. We tell
   developers they got deadlines to run their code to keep their apps
   responsive, but it’s hard for them to achieve that.
   - Ryosuke: Is the goal to increase user responsiveness?
   - Shubhie: Increase responsiveness for input (100ms), frmae rates (10ms)
   - Scott: FIFO gives you some order, and user facing experience metrics
   depend on that order. And current order is not optimal
   - Ryosuke: what are we trying to optimize?
   - Shubhie: user input
   - Scott: Also loading metrics, scripts can be responsible for rendering
   - Shubhie: Also FID
   - Ilya: I assume the explainer spells out the motivation
   - Shubhie: yes, the explainer has the motivations
   - Ilya: Maybe take an AI to read through that and come back with feedback
   - Will: When we talk about optimizing for the user, is that the end user
   or the developer?
   - Shubhie: helping the web developer to achieve end-user expectations
   - Ryosuke: Sounds like the criteria will be based on the case studies,
   build something with the new API and measure that
   - Andrew: Speaking for React, we wanted isUserPending to make sure task
   throughput is high. The high level API needs to keep that throughput.
   - Shubhie: We’ll get experimentation results from partners.
   - Ryosuke: if you have a priority you want to have a priority inversion
   - Todd: When we move to dynamic, what will happen?


   - There can be priority inversions in case of timeouts. High priority
   work can get stuck behind low priority work. We also have priority
   inversion now, where scheduling high priority work is stuck behind
   everything. So it won’t make things worse.


   - Ryosuke: Not worse, but seems like *the* thing we want to solve here
   - Scott: the MVP includes a way to change priorities. So you’d be able
   to build priority systems in userspace based on that
   - Shubhie: The maps use-case, when the user is panning the map, the
   highest priority is fetching the tiles, but user behavior change can mean
   we need to do something else right now. Developers need a way to indicate
   priority change
   - Scott: With virtual task queues as a subset of task queues, you’d be
   able to move tasks between the queues. You could create a periodic high
   priority task that changes priorities. Virtual task queues will enable
   userspace scripts to change priorities on their own.
   - Shubhie: can add scenarios to the explainer.
   - Ryosuke: Have you talked to Android scheduler folks? Relying on users
   to adjust priorities is tricky. In iOS, user interaction is highest
   priority and adjustments are done automatically. Might be better to define
   dependencies.
   - Ben: Appreciate the context given by Google Maps panning example.
   Willing to file issues on WICG. Context is super helpful
   - Ryosuke: Also would be great to update GH with what was presented.

JS Self-Profiling feedback and updates
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1Ex_bD6oMLirboYYWJnUBySbw2i8fzb143P1lNenLNAI/edit?usp%3Dsharing&sa=D&ust=1557326850425000>
 - acomminos@fb.com


   - Andrew: presenting


   - Focused on cross-origin concerns and evaluate feasibility through
   Blink implementation
   - So far so good, and crossorigin script situation uses current infra
   - Main issues


   - Symbolization map before profiling is fairly expensive - CPU and memory
   - Trace sizes are about what we expected
   - Testing is a bit challenging - no SLA to what sampling rate


   - Symbolication


   - Either always build the codemap but expensive when not used
   - Lazily building it is not great, as it’s done on the VM thread. Can
   also leak data


   - 200-300ms on high end desktop machine


   - Greedy is best, if we know we need it
   - Maybe declaring it through feature policy. Since it’s restricted to
   frames, it kinda works
   - Increases the overhead of deploying that.


   - Ilya: the flow - site operator sets a policy that enables the profiler?
   - Andrew: yeah
   - Ilya: Why not through JS?
   - Andrew: because the creation stops the VM and can leak info?
   - Todd: Is that a Blink implementation issue?
   - Andrew: Talked to Markus
   - Markus: It might be possible to avoid it, but Firefox will have the
   same problem
   - Todd: Chakra could have done that, but not sure that
   - Yoav: header registration may be enough, so Feature Policy may be an
   overkill
   - Tim: Slightly different as we want to enable measurement, not
   necessarily start it
   - Andrew: Not married to FP


   - Trace format: Form of structural compression. Do we need to add gzip
   or other compression. Deduping URLs was a big win. Gzip blobs may not be
   great for everyone, as some consumers may not need some of the trace.


   - Yoav: gzip in the browser may be a good complement to that
   - Andrew: have success with a wasm impl of snappy compression


   - Trace sizes - 22KB gzipped


   - Ilya: doesn’t seem too scary
   - Nic: 22KB gzipped is on the upper end of what we can get away with
   - Tim: what about the 10ms sample rate? You can get away with slower
   sampling
   - Andrew: yeah, measured worst case scenario


   - Testing - spec doesn’t provide guarantees to sampling rate


   - Yoav: You can maybe enforce sampling using a webdriver API
   - Andrew: sure. Web driver sounds good. Would be better if we could test
   directly


   - Callback - DOM callback

<out of time>



On Thu, May 2, 2019 at 12:54 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Let's talk about designs!!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.z70m44vqh4e1>,
> we have Scott Haseley that will talk about Main Thread Scheduling and
> Andrew Comminos that will discuss JS Self-Profiling feedback and updates.
>
> Please join us on our brand new hangout
> <https://meet.google.com/agz-fbji-spp>!
>
> Cheers :)
> Yoav
>
>