Out of curiosity - What is performance like on a low tier Android phone (I see only a Pixel 7 tested above)? What is the performance of your benchmark on other browsers - across device classes? (Even if they don't have this limit - this intent will mean that it'll be interoperable to use the sync method - potentially causing compat problems for the other browsers).
Ian On Fri, Apr 14, 2023 at 2:00 AM 'Andreas Haas' via blink-dev < blink-dev@chromium.org> wrote: > Hi Alex, > > Here are the performance numbers that I collected: > https://docs.google.com/document/d/1hOGwCurQmPF_GZdflsJno286sJXgfoLeOGaUhZuMzCQ/edit?usp=sharing > > I think the question is more, how can we justify such a limit? I mean, I > agree, it is not a good experience if the main thread is blocked for 1 > second, but we have to consider the scenario in which this is happening. > The main thread is blocked for one second after a WebAssembly module was > downloaded which is tens of megabytes big. > > Additionally, in the current environment it is not likely that you end up > serving a big WebAssembly module to the user with synchronous compilation > by accident. WebAssembly modules are typically generated by compilers which > also generate the JS glue code around it. These compilers produce glue code > that uses asynchronous compilation or even streaming compilation. Therefore > a developer would have to make an effort to even serve a big WebAssembly > module with synchronous compilation. > > There are scenarios where developers make this effort, and I don't think > we should prevent developers when they make this conscious decision. One > such scenario is tests. It is much easier to write and run tests with > synchronous compilation. We run nearly all our WebAssembly tests in V8 with > synchronous compilation. We also got bug reports repeatedly where > developers struggle with their tests because of the 4KB limit. > > So overall I think the limit was justified in the beginning, but now with > lazy compilation and baseline compilation this justification is gone. I > don't think this limit makes the web a better place anymore, it just makes > the life of developers difficult in specific niche situations. > > Cheers, Andreas > > On Thu, Apr 13, 2023 at 8:21 PM Alex Russell <slightly...@chromium.org> > wrote: > >> "Below 1 second" for something that can block the main thread is not >> particularly heartening. Can you please provide the histogram data you're >> seeing to justify this? Would you be happy to raise the cap to a larger >> (but still fixed) size based on a baseline device config instead?, e.g.: >> >> https://infrequently.org/2022/12/performance-baseline-2023/ >> >> Best, >> >> Alex >> On Wednesday, April 5, 2023 at 7:09:15 AM UTC-7 Andreas Haas wrote: >> >>> Hi Yoav, >>> >>> I'm not sure what you mean. At the moment this 4KB limit exists in >>> Chrome, but it does not exist in Safari or Firefox. I tested this locally >>> on my Macbook. I don't know if there exists another test at the moment >>> which passes on Safari and Firefox but fails on Chrome, and would pass on >>> Chrome after we remove the limit. >>> >>> Cheers, Andreas >>> >>> On Wed, Apr 5, 2023 at 3:57 PM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Wed, Apr 5, 2023 at 3:05 PM 'Andreas Haas' via blink-dev < >>>> blink-dev@chromium.org> wrote: >>>> >>>>> Contact emailsah...@google.com >>>>> >>>>> ExplainerNone >>>>> >>>>> SpecificationNone >>>>> >>>>> Summary >>>>> >>>>> There exists a limit on the size of a module that can be compiled with >>>>> `new WebAssembly.Module()` on the main thread. This limit is 4KB, and it >>>>> was introduced when WebAssembly modules got compiled eagerly with an >>>>> optimizing compiler, which could block the main thread for many seconds >>>>> and >>>>> even minutes. In the meantime V8 launched lazy compilation for WebAssembly >>>>> modules, and the execution time of `new WebAssembly.Module()` is below 1 >>>>> second even for the biggest modules we see, even on the weakest devices we >>>>> measured. Therefore it is time to remove this limit. >>>>> >>>>> >>>>> Blink componentBlink>JavaScript>WebAssembly >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> >>>>> >>>>> TAG reviewNone >>>>> >>>>> TAG review statusNot applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> >>>>> >>>>> *Gecko*: Shipped/Shipping >>>>> >>>>> *WebKit*: Shipped/Shipping >>>>> >>>>> *Web developers*: Strongly positive We received repeated bug reports >>>>> because of this limit. Especially for tests synchronous compilation with >>>>> `new WebAssembly.Module()` is useful, but the size limit prevents bigger >>>>> tests from using synchronous compilation. >>>>> >>>>> *Other signals*: >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> >>>>> None >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ?No >>>>> >>>> >>>> Is it interoperably tested by other means? I'm not super familiar with >>>> WASM testing.. >>>> >>>> >>>>> >>>>> >>>>> Flag name >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Estimated milestones >>>>> Shipping on desktop 114 >>>>> Shipping on Android 114 >>>>> Shipping on WebView 114 >>>>> >>>>> Anticipated spec changes >>>>> >>>>> Open questions about a feature may be a source of future web compat or >>>>> interop issues. Please list open issues (e.g. links to known github issues >>>>> in the project for the feature specification) whose resolution may >>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>> of >>>>> the API in a non-backward-compatible way). >>>>> None >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5080569152536576 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/>. >>>>> >>>>> -- >>>>> >>>>> Andreas Haas >>>>> >>>>> Software Engineer >>>>> >>>>> ah...@google.com >>>>> >>>>> >>>>> Google Germany GmbH >>>>> >>>>> Erika-Mann-Straße 33 >>>>> >>>>> 80636 München >>>>> >>>>> >>>>> Geschäftsführer: Paul Manicle, Liana Sebastian >>>>> >>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>> >>>>> Sitz der Gesellschaft: Hamburg >>>>> >>>>> >>>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise >>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>> bitte >>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>>> >>>>> >>>>> >>>>> This e-mail is confidential. If you received this communication by >>>>> mistake, please don't forward it to anyone else, please erase all copies >>>>> and attachments, and please let me know that it has gone to the wrong >>>>> person. >>>>> >>>>> -- >>>>> 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+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>> >>> -- >>> >>> Andreas Haas >>> >>> Software Engineer >>> >>> ah...@google.com >>> >>> >>> Google Germany GmbH >>> >>> Erika-Mann-Straße 33 >>> >>> 80636 München >>> >>> >>> Geschäftsführer: Paul Manicle, Liana Sebastian >>> >>> Registergericht und -nummer: Hamburg, HRB 86891 >>> >>> Sitz der Gesellschaft: Hamburg >>> >>> >>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten >>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >>> dass die E-Mail an die falsche Person gesendet wurde. >>> >>> >>> >>> This e-mail is confidential. If you received this communication by >>> mistake, please don't forward it to anyone else, please erase all copies >>> and attachments, and please let me know that it has gone to the wrong >>> person. >>> >>> > > -- > > Andreas Haas > > Software Engineer > > ah...@google.com > > > Google Germany GmbH > > Erika-Mann-Straße 33 > > 80636 München > > > Geschäftsführer: Paul Manicle, Liana Sebastian > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > > Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > > -- > 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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpTaGWmmUwiLGrBoJxcYMD782Ms6qE5wi67wjqOfgSCGKA%40mail.gmail.com.