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

[Takashi Toyoshima]

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

Feel free to send any feedback.

Updates:

• ES6 modules

• Performance (ksakamoto, kouhei)

• Ksakamoto: Module loading performance report

• Kouhei: Un-webpacking airbnb to find out real-world use cases.

• Dynamic imports (kouhei)

• Classic script CSP test passes

• Mojo-Loading

• Investigated UMAs further.

• The crash bcwhite@ fixed originated from M61 but we saw the crash rate difference in M60 (bad news)

• I see some mojo::edk::Watcher* crashes after bcwhite@’s fix (bad news)

• The difference in M60 was not observed originally. It suddenly went up around Aug 23. I found that the difference was not from Chrome version difference (event fixing the version the sudden increase is observed).

• We saw a significant crash rate increase on M61 beta in Aug but the crash rate increase on M62 beta in Sep looks better even without bcwhite@’s fix (good news).

• 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]

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]

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]

[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.

[block.rxc...@gmail.com]

> Do you mean if we pack multiple modules with native format like Web Packaging it will change the situation?

Yes

my point of view is number of request are dominant.

if web-packaging could packs multiple module files into single pack, and browser can fetch/unpack them and handle if there are multi fetched module files localy.

so if web-packaging (currently only a draft) enables that.

we seems be able to say...

if there are too many modules and

- network cost are bottleneck -> pack them in single file

- ipc cost are bottleneck -> bundle them in single file (with tree shake and inlining optimization)

if this true, I think 1st is good use-case to feedback to https://tools.ietf.org/html/draft-yasskin-dispatch-web-packaging-00

but 

> However, there are some important differences to note:

> - module scripts may import other module scripts

> - module scripts are compiled before being scheduled to run

that make sense, and finally we need bundling in mid/large project...

(personally, I hate bundling with who takes long build time and makes debugging bit hard. and expected to modules free from webpack)

[Kouhei Ueno]

By the way let us stress that the measurements/recommendations are as of M63/ToT, and the purpose of the documents are to clarify where we are and where we should focus our optimization efforts in future. We are not satisfied of module loading performance as is, and the scene/recommendations are expected to change for M64+.

On Fri, Oct 13, 2017 at 2:17 PM, block.rxc...@gmail.com <block.rxc...@gmail.com> wrote:

> Do you mean if we pack multiple modules with native format like Web Packaging it will change the situation?

Yes

my point of view is number of request are dominant.

if web-packaging could packs multiple module files into single pack, and browser can fetch/unpack them and handle if there are multi fetched module files localy.

so if web-packaging (currently only a draft) enables that.

we seems be able to say...

if there are too many modules and

- network cost are bottleneck -> pack them in single file

- ipc cost are bottleneck -> bundle them in single file (with tree shake and inlining optimization)

These are true as of M63. However, there are a lot of optimizations that browser can do for both network/ipc that we haven’t yet done. I think it is too early to conclude that tree shake + bundling is required in long run. 

 

if this true, I think 1st is good use-case to feedback to https://tools.ietf.org/html/draft-yasskin-dispatch-web-packaging-00

Yes. We are in touch with the webpackaging team.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAMaRJ1NKr3UA%2B-zvvy56XUnDbOsiv49-%3Dte3bCo5%2BNo8TM8Euw%40mail.gmail.com.

--

kouhei