Loading Tokyo Team weekly snippet (Sep 30 - Oct 6)

36 views
Skip to first unread message

Takashi Toyoshima

unread,
Oct 11, 2017, 3:30:51 AM10/11/17
to blink-dev, Chromium Loading Performance, Chromium-dev

We, Loading Tokyo team, experimentally start sending weekly snippets.

Feel free to send any feedback.


Updates:

  • ES6 modules

    • Performance (ksakamoto, kouhei)

    • Dynamic imports (kouhei)

      • Classic script CSP test passes

  • Mojo-Loading

  • Servicification

    • Wrote SimpleURLLoader migration plan (kinuko@, mmenke@): doc

    • Redirect handling changes

      • Redirect handling needs to be done by multiple URLLoaderClient implementors (and also we still need it in //net)

      • NavigationURLLoaderNetworkService doing same/similar to what net::URLRequest::Redirect does, we also need something similar to SW subresource handling in the renderer process

      • Plan: will have common redirect code for all these (e.g. net::RedirectUtil::UpdateHttpHeader)

  • Out-of-Blink CORS

    • Make the WebCORSPreflightResultCache back to be thread local. (crrev.com/67d4e60)

    • Add spec links for fetch related enums

    • DocumentThreadableLoader: stop recording JS initiated non-GET fetches

    • WebCORS: mechanical style and comment fixes

    • CORSURLLoaderTest

  • Origin Manifest

    • Kick-off meeting with Munich

    • Design doc review

  • More predictable MemoryCache

    • As a follow-up for the discussion done in SpeedConvergence, japhet@ landed yet another patch not to retain resources if the navigation is cross-site.

    • hiroshige@ will help with experiment set-up

  • Scalable loading / 10k measurement

    • Wrote a doc for 10k measurement with recent perf measurement updates

    • Asked by Addy (for CDS etc), being also asked by FB

    • Waiting for ksakamoto@’s sign-off before circulating more widely

  • WebFonts (toyoshim)

    • Intervention V2 launch efforts

      • WebFontsIntervensionV2: experiment-controlled rollouts, step 1 (cr/170663524)

      • WebFontsIntervensionV2: experiment-controlled rollouts, step 2 (cr/171101260)

      • WebFonts intervention: remove ios from the platform list (cr/171120195)

      • WebFonts intervention: Enable v2 by default

      • WebFontsIntervensionV2: experiment-controlled rollouts, step 3

    • Review ExecutionContext related crash fix changes

  • Fetch keepalive

    • KeepAliveRendererForKeepaliveRequest looks good. I’ll just enable it if no one complains.

    • Preparing intent-to-implement.

  • ResourceLoadScheduler (toyoshim)

    • Verify if AMP works fine with our throttling

    • ResourceLoadScheduler: add a sub-frame specific param to limit requests (crrev.com/f2f17ad)

    • ResourceLoadScheduler: update configurations to use bg_sub_limit (cr/171254049)



--
Takashi Toyoshima
Software Engineer, Google

kai zhu

unread,
Oct 11, 2017, 8:50:28 AM10/11/17
to Takashi Toyoshima, blink-dev, Chromium Loading Performance, Chromium-dev
appreciate the update on profiling es6-modules.  this is the first i've heard of anyone taking a serious look on its performance impact (vs hand-waving blather by bloggers).  i personally remain skeptical es6-modules will ever match the load-time performance of classical-scripts, but the loading-team can think of that as a challenge to surprise me ; )

-kai

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFWCB1nZ%3DHWcbTCZk7rt4iJJuAMS_fCOZPfPN%3DT10zxUwxpRJQ%40mail.gmail.com.

jxck jxck

unread,
Oct 12, 2017, 9:44:13 PM10/12/17
to blink-dev, loadi...@chromium.org, chromi...@chromium.org
ES6 Module Performance is so interesting to read.

result of measuring Module vs Bundled seems similar to MultiFile vs SingleFile for me.
(so `Module` or `Scripts` are less influence for this result).

if web-packaging will packs multi modules to single file, will works fine for update Recommendation ?

Jxck

2017年10月11日水曜日 16時30分51秒 UTC+9 Takashi Toyoshima:

Kunihiko Sakamoto

unread,
Oct 13, 2017, 12:16:18 AM10/13/17
to jxck jxck, Chromium Loading Performance

[bcc: blink-dev, chromium-dev]


> result of measuring Module vs Bundled seems similar to MultiFile vs SingleFile for me.

> (so `Module` or `Scripts` are less influence for this result).


Yes. Looking at the current trace analysis, the current bottlenecks seem common for both {module,classic} script cases. (You can see where bottleneck comes in many-scripts/modules cases here too)


However, there are some important differences to note:

- module scripts may import other module scripts

- module scripts are compiled before being scheduled to run


> if web-packaging will packs multi modules to single file, will works fine for update Recommendation ?


Do you mean if we pack multiple modules with native format like Web Packaging it will change the situation? It’d largely depend on how it would be implemented and we don’t have a clear answer for that yet.



--
You received this message because you are subscribed to the Google Groups "loading-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/53dd13b7-8324-41f8-90c3-d2329f905feb%40chromium.org.

Reply all
Reply to author
Forward
0 new messages