[web:canvaskit] severe performance regression in text layout

[yjbanov]

Multiple text layout benchmarks regressed by 3.5x. This started with #123423. The only thing in that roll that seems relevant is flutter/engine#40470. That change only flips the default build of CanvasKit from unpkg to the local build. I thought we were already using local build, so this is surprising. Maybe we were still hitting the NPM build in benchmarks. Perhaps the issue is in the Chromium build (cc @mdebbar). Could this be v8BreakIterator related? Should we cache string fragmentation results?

Skia Perf: https://flutter-flutter-perf.skia.org/e/?queries=sub_result%3Dtext_canvaskit_layout.canvaskit.single_line.layout.average%26sub_result%3Dtext_canvaskit_layout.canvaskit.multi_line.layout.average%26sub_result%3Dtext_canvaskit_layout.canvaskit.max_lines.layout.average%26sub_result%3Dtext_canvaskit_layout.canvaskit.ellipsis.layout.average&selected=commit%3D33995%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253Dnone%252Cdevice_version%253Dnone%252Chost_type%253Dlinux%252Csub_result%253Dtext_canvaskit_layout.canvaskit.max_lines.layout.average%252Ctest%253Dweb_benchmarks_canvaskit%252C

[iapicca]

possibly related to

• Memory leak on flutter web when using Icon in ListView #122189
• [MacOS][Web] The scrolling performance degradation #123204
• Flutter web is too slow to open tabs with table #123404

[jason-simmons]

With flutter/engine#40470 apps will use the local copy of CanvasKit obtained from the flutter_tools cache instead of downloading from unpkg. The version of CanvasKit in the tools cache comes from the flutter_web_sdk artifact, which is built by Flutter CI from the engine tree.

The major difference I noticed between the engine's CanvasKit build and Skia's is that the engine is using -Oz optimization in Emscripten compile commands. Skia is using -O3.

Confirmed that the benchmarks produce similar results to before the regression if I patch the engine buildroot to use -O3 for Wasm compilation.

[mdebbar]

It's possible that this is related to the Chromium build of CanvasKit. We don't know because we did both switches at the same time (unpkg => local build and canvaskit => canvaskit chromium).

If CanvasKit Chromium is slower than the regular CanvasKit, then there are a few areas that could be contributing to this:

1. Browser APIs themselves (i.e. Intl.Segmenter and v8BreakIterator).
2. Our glue code that uses browser APIs to gather the required ICU information.
3. Data-passing between the engine and CK.