LGTM2 Thanks for testing this! :)
On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas <ah...@google.com> wrote: > Hi Philip, Yoav, > > I added a test to the wasm spec tests now, see > https://github.com/WebAssembly/spec/pull/1642. It creates modules of size > 1GB and 1GB+1 and checks that compilation passes or fails, respectively. > The modules consist of a single custom section, so that minimal processing > time and module creation time should be introduced. > > As far as I know, the other browsers never had a special limit on the > module size, other than the spec'ed 1GB limit. I confirmed that now with > Firefox. > > Cheers, Andreas > > On Wed, Apr 19, 2023 at 5:59 PM Philip Jägenstedt <foo...@chromium.org> > wrote: > >> Hey Andreas, >> >> Do you know what the limits of other browsers are? If testing a 1 GB >> module is too slow to be reliable (sometimes timing out) then perhaps >> there's a large-ish module you can test with that still exceeds the current >> limits? >> >> Note that you could also add a manual test in WPT for the real limit (1 >> GB) and run it at least once manually to ensure it works the same in all >> browsers. >> >> Best regards, >> Philip >> >> On Mon, Apr 17, 2023 at 12:12 PM 'Andreas Haas' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> Hi Ian, >>> >>> Here is the benchmark: x20.corp.google.com/users/ah/ahaas/index.html >>> >>> You need corp access for it, and I didn't have access to low tier >>> Android phones with corp access. >>> >>> Safari also compiles lazily, so their compile times are similar to ours. >>> Firefox compiles modules eagerly, and therefore takes longer. I don't >>> really have the devices or the setup to do the measurements on other >>> browsers. I measured the performance of Firefox on my workstation, where >>> the compilation of the 80MB module takes slightly less than 1.6 seconds. >>> This is about 60% slower than Chrome with eager compilation. I tried Chrome >>> with eager compilation on the atlas Chromebook. Compilation of the 80MB >>> module takes 2.8 seconds there. >>> >>> Cheers, Andreas >>> >>> On Fri, Apr 14, 2023 at 8:18 PM Ian Kilpatrick <ikilpatr...@chromium.org> >>> wrote: >>> >>>> 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> >>>>> . >>>>> >>>> >>> >>> -- >>> >>> 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/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%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. > > -- 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/CAL5BFfXE7kp8Pq92k4Ju5w9hq7kv0%3DduebA9tRPUSTkBgEMp-w%40mail.gmail.com.
