[dart2wasm] Investigate switching to JS strings: What are perf/size implications?

[mkustermann]

Now that we have a js-string builtin proposal implemented and optimized in Wasm runtimes (e.g. V8), we should investigate switching to JS strings: What are perf/size implications?

If we cannot switch, we may look into having a bi-directional cache of strings, so repeated <dartString>.toJS will only do work on the first invocation and use the cached version afterwards. See also flutter/flutter#159400

[rydmike]

Thanks @mkustermann for filing this issue.

Since the source of this issue, here flutter/flutter#159400, is auto locked (apologies, I was busy and did not have time to respond in time before it got locked), I added some replies to it here.

Looking at the code in flex_color_scheme/example/lib/shared/widgets/universal/syntax_highlighter.dart it's obvious why this is slow: For every token it scans, it uses a regexp to match it. And every time we match a regexp we copy the entire dart source (which is very large compared to the actual token) to JS. So effectively this is O(n^2) instead of O(n).

Yes I'm aware it is not performant. It is a copy of Google's short and simple syntax highlight code from the old Flutter Gallery app. As it only deals with very short code to highlight, it never needed to be very efficient.

Regardless, in Javascript and native VM builds it handles theme transitions well enough, and even manages to animate color changes in the highlight colors as theme changes, without any major issues. Sure it is not super fast, but works well enough. It thus felt kind of expected that if it worked fast enough in Javascript that it should run as fast, if not even faster, in a WASM build. It was surprising to learn that using WASM makes the entire app build not viable, since it is in a pretty critical part for the app in question. Which of course imo, makes it an interesting find.

One unrelated thing that sticks out most in the profile is e.g. ColorTools.nameThatColor, which is implemented by linear scan over colors and doing lots of math operates for each, see here. This seems not very ideal, better would be a cache (if it's called often for same color) or spacial index (to avoid linear scan), ...

Yeah not related, but yes I agree and 100% aware of this one being very sub optimal. A cache would help, but it would take some time to warm it up for it to have an impact. Every color in the RGB space, will get one of the 1565 named colors assigned as its "name", the one being "visually closest" to the actual named color value. Since we do not know which one it will be and the app can use any color in RGB space, potentially for a fully cached situation it would mean a map with every color in RGB space and its resulting name. We could thus even pre-compute the cache map for every color in RGB space, it would use a bit of memory, but it could certainly be done and would be fast to use. BTW, this naming tool is a port of Javascript "Name That Color". It's usage is not at all critical for the app, but kind of fun that all colors get some name :)

That the color names lerp animate during theme transition is not at all important, just a fun thing, and while quite heavy in its current form, still works well enough, even in the WASM build.

---

At the moment it does however sound like that the only way we can make a viable WASM build of the Themes Playground is by removing/disabling features that work well enough already in JS and VM builds.

What could be done is to only change the theme highlight colors once, after a theme change animation transition is complete, so they do not animate during the theme change. This is of course the kind of ugly transition I'm trying to avoid. It would not be so bad in light-to-light or dark-to-dark theme changes, but in light to dark and vice versa, it would look horrific.

Additionally, since there is no built-in event in Flutter for when a Theme transition has completed, I would have to make my own hacked trigger for that, doable, but not pretty.

Alternatively, we could of course also investigate other Dart code highlight packages that might not have this performance issue in a WASM build, when theme transition animating its code highlight colors. Who knows, I might find one. The point with the used approach was originally that, while it was a naive approach, it was short and did not require any package, and worked well enough for a few hundred lines of code, which was all that was needed.

The same solution, to only update once, after a theme transition, could of course also be used with the lerp animated "Name that color" changing names, and only update their names ones a Theme transition has completed. Here it would not matter so much visually, so for them it would not really matter and it would work well as an alternative to caching. That the names also lerp animate with the theme transitions was actually a bit of fun side effect when the name lookups were originally added. Since it worked well enough (still kind of does in WASM too), I left it in there, despite the perf hit.

---

@kevmoo, if you happen to drive by. Here is a little teaser. We got a pretty cool WASM-GC build going public soon. It has roughly 400kLoC Flutter code, plus even more C++ code compiled to WASM and using WebGPU with a custom renderer. Also interesting, on Android the newer Flutter builds will finally use Impeller/Vulcan as well, so we can use our newer custom renderer there too. More later ;)

We got some useful insights into the Flutter WASM builds via the issues I posted concerning the Playground, so the helpful assists and replies have been welcome there too :)

[kevmoo]

Again, thanks so much for digging in here @rydmike! Excited to see what you end up with.

[mkustermann]

We have now switched to JS strings and it should have rolled up to flutter main branch by now.

Overall this should solve the performance issue of using regular expressions where we repeatedly copy Dart strings to JS strings: Now we use JS strings as only string implementation.

@rydmike This should solve the big performance issue you have noticed. Please let us know if you run into any performance issues - we'd be happy to take a look.

[rydmike]

Awesome 👍 Thanks @mkustermann, I will make a test build and Wasm deployment using master, tonight or tomorrow, and test it out.