Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

Thank you very much!

On Tue, May 9, 2023 at 11:00 PM Chris Harrelson 
wrote:

> LGTM3 to change the limit to 8MB, for the reasons Andreas outlined
> (maximum function size, reasonable runtime on a low-end phone).
>
> Also, I can totally see increasing the limit in the future, as the
> implementation is optimized further, typical hardware speeds increase, or
> there are compelling examples of developer use cases that come up. For now,
> 8MB seems a reasonable & conservative choice.
>
> Thanks Andreas for your patience on this thread, and for providing such
> useful data points!
>
> Chris
>
> On Thu, May 4, 2023 at 9:13 PM Elliott Sprehn 
> wrote:
>
>>
>>
>> On Thu, May 4, 2023 at 6:40 AM Andreas Haas  wrote:
>>
>>> Hi Yoav, PhistucK,
>>>
>>> [...]
>>>
>>
>>
>>> My problem now is that with the higher limit we still violate the spec,
>>> an with the spec test I introduced during this discussion the spec
>>> violation is even more visible. As someone wrote before, a solution to this
>>> problem could be to change the spec, but the same as there is no reason to
>>> keep or remove the limit in Chrome, there is no reason to introduce such a
>>> limit into the spec.
>>>
>>>
>> Multiple experts in web performance have given reasons to keep the limit
>> in this thread. That would be the reason to introduce it to the spec.
>>
>> - E
>>
>> --
>> 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/CAPKeNH%3DnkK6o8mZUHazY-QU6jH8O4Yw9UNqt8sb%2B8PCLaCfU%2Bg%40mail.gmail.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/CAELSTvdE6CkWgTw6UARn%2BmiErA%2Bd0prXQmvXn8S0WTT7-1PMrg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Chris Harrelson]

LGTM3 to change the limit to 8MB, for the reasons Andreas outlined (maximum
function size, reasonable runtime on a low-end phone).

Also, I can totally see increasing the limit in the future, as the
implementation is optimized further, typical hardware speeds increase, or
there are compelling examples of developer use cases that come up. For now,
8MB seems a reasonable & conservative choice.

Thanks Andreas for your patience on this thread, and for providing such
useful data points!

Chris

On Thu, May 4, 2023 at 9:13 PM Elliott Sprehn  wrote:

>
>
> On Thu, May 4, 2023 at 6:40 AM Andreas Haas  wrote:
>
>> Hi Yoav, PhistucK,
>>
>> [...]
>>
>
>
>> My problem now is that with the higher limit we still violate the spec,
>> an with the spec test I introduced during this discussion the spec
>> violation is even more visible. As someone wrote before, a solution to this
>> problem could be to change the spec, but the same as there is no reason to
>> keep or remove the limit in Chrome, there is no reason to introduce such a
>> limit into the spec.
>>
>>
> Multiple experts in web performance have given reasons to keep the limit
> in this thread. That would be the reason to introduce it to the spec.
>
> - E
>
> --
> 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/CAPKeNH%3DnkK6o8mZUHazY-QU6jH8O4Yw9UNqt8sb%2B8PCLaCfU%2Bg%40mail.gmail.com
> 
> .
>

-- 
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/CAOMQ%2Bw-VQ9j62wGcKmJ1bc4j5dkLzHshz5KZGrP7G7OD_4_CGA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Elliott Sprehn]

On Thu, May 4, 2023 at 6:40 AM Andreas Haas  wrote:

> Hi Yoav, PhistucK,
>
> [...]
>


> My problem now is that with the higher limit we still violate the spec, an
> with the spec test I introduced during this discussion the spec violation
> is even more visible. As someone wrote before, a solution to this problem
> could be to change the spec, but the same as there is no reason to keep or
> remove the limit in Chrome, there is no reason to introduce such a limit
> into the spec.
>
>
Multiple experts in web performance have given reasons to keep the limit in
this thread. That would be the reason to introduce it to the spec.

- E

-- 
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/CAPKeNH%3DnkK6o8mZUHazY-QU6jH8O4Yw9UNqt8sb%2B8PCLaCfU%2Bg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Andy Wingo]

Hi,

Just a note about use-cases:

On Fri 21 Apr 2023 13:47, "'Andreas Haas' via blink-dev" 
 writes:

> * You don't write WebAssembly modules by hand, you generate them with
> a compiler like Emscripten.

The WebAssembly module itself may well generate, compile, and
instantiate a module -- a form of JIT code generation.  See
https://wingolog.org/archives/2022/08/18/just-in-time-code-generation-within-webassembly
for a longer discussion.  Probably at some point there will be a
WebAssembly proposal to address this use case.

Sometimes synchronous compilation can be useful for the JIT use case,
for example so you can embed pointers to linear memory in the generated
module and be sure they are still valid by the time the generated module
runs.  Of course, generally you would still want to design for
asynchronous compilation to avoid blocking the main loop, but in
development at least it's nice that synchronous instantiation is
possible.

Regards,

Andy

-- 
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/87fs8ngky5.fsf%40igalia.com.

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Alex Russell]

  Hey Andreas,

First, I deeply appreciate your willingness to do the work to get us data.

I'm generally interested in understanding the potential for modules to 
create main-thread jank. If we accept the CWV INP threshold of ~200ms, 
would like to make sure that for the vast majority of users (P90? P95?) 
don't hit synchronous operations longer than that. So the question about 
sizing is relative to that goal.

Put differently, if we raise the limit to XMB vs. YMB, and developers begin 
to develop to that new threshold, how much jank can this introduce?

As for "does blocking the main thread for 1s really matter?", all I can 
tell you is that this project has worked diligently for more than a decade 
to try to eliminate sources of main-thread jank. It would be surprising if 
we relaxed that goal for this specific feature.

Best,

Alex



On Friday, April 21, 2023 at 4:47:29 AM UTC-7 Andreas Haas wrote:

> Hi Alex,
>
> I will try to organize a low-end device to do the measurements you are 
> asking for. Could you please describe how the results would guide your 
> decision on this issue?
>
> I would also ask you to clarify your concerns. What are the scenarios you 
> have in mind, and what are the improvements a user would get from this 
> limit?
>
> When I think of concrete scenarios, then I end up either with the scenario 
> being unlikely, or that the limit would not make a big difference for the 
> user experience:
> * Unlikely, because it is hard to end up with a big WebAssembly module 
> that you compile synchronously. You don't write WebAssembly modules by 
> hand, you generate them with a compiler like Emscripten. The compiler 
> typically does not only generate the WebAssembly module for you, it also 
> generates the code for you that downloads and compiles the WebAssembly 
> module. A scenario where the limit may matter is that the compiler decides 
> to use synchronous compilation instead of asynchronous compilation. 
> However, why would the compiler do that?
> * Because synchronous compilation provides benefits? What would these 
> benefits be? The WebAssembly module already gets downloaded asynchronously, 
> so continuing with synchronous compilation has no advantage to asynchronous 
> compilation.
> * By accident, because the compiler writer does not know better? I 
> think it's unlikely that a compiler writer would choose to use synchronous 
> compilation by accident, and that this compiler is then used to produce a 
> WebAssembly module with 10s of MB, and that the resulting WebAssembly 
> module is then used in any reasonable webpage.
> * The limit would not make a difference for the following reason: On the 
> website you cite above the average network bandwidth is 9Mbps. Even 
> compressed the 80MB module in my measurements would take 10s of seconds to 
> download. Does blocking the main thread of less than 1 second really matter 
> to the user after they waited many times as long for the download?
>
> As I wrote before, I understand why this limit was introduced originally. 
> However, these reasons don't exist anymore, and all that remains is a spec 
> violation, see https://webassembly.github.io/spec/js-api/index.html#limits. 
> Even a limit of 10MB is still a spec violation, and as I wrote before, I 
> don't see any justification for that.
>
> Cheers, Andreas
>
> On Thu, Apr 20, 2023 at 8:58 PM Alex Russell  
> wrote:
>
>> Thanks for the document, Andreas.
>>
>> The numbers in it are still hugely concerning, and I'm a -1 until and 
>> unless we have data from P75-P90 Androids and Windows devices. Our 
>> telemetry from Edge shows that nearly half of users are on slow, spinning 
>> rust and 2-4 core devices, and the only system in your test list that 
>> reflects something in this range is the N2840 in the HP Chromebook 13 G1.
>>
>> Motivations in the document regarding testing are not compelling. Folks 
>> doing testing can provide flags to the browser (which you could expose to 
>> raise the limit without an Intent).
>>
>> Would you be willing to accept a higher cap? Your document suggests that 
>> ~10MiB (unzipped) might be reasonable, but would want to see data from 
>> low-end Android before going even that far.
>>
>> Thanks.
>>
>> On Thursday, April 20, 2023 at 4:06:30 AM UTC-7 Yoav Weiss wrote:
>>
>>> LGTM2
>>>
>>> Thanks for testing this! :)
>>>
>>> On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas  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, 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[K. Moon]

I don't have any authority here, but my two cents: Given there's a
synchronous and an asynchronous API already, why not let the page author
decide the right trade-off for themselves? I know in general we'd like to
discourage authors from blocking the renderer main thread, but there
already seem to be plenty of incentives not to do that already, and the
well-lit paths don't encourage large synchronous compilations. It'd be
different if this somehow required blocking the browser main thread, of
course.

On Fri, Apr 21, 2023, 4:47 AM 'Andreas Haas' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi Alex,
>
> I will try to organize a low-end device to do the measurements you are
> asking for. Could you please describe how the results would guide your
> decision on this issue?
>
> I would also ask you to clarify your concerns. What are the scenarios you
> have in mind, and what are the improvements a user would get from this
> limit?
>
> When I think of concrete scenarios, then I end up either with the scenario
> being unlikely, or that the limit would not make a big difference for the
> user experience:
> * Unlikely, because it is hard to end up with a big WebAssembly module
> that you compile synchronously. You don't write WebAssembly modules by
> hand, you generate them with a compiler like Emscripten. The compiler
> typically does not only generate the WebAssembly module for you, it also
> generates the code for you that downloads and compiles the WebAssembly
> module. A scenario where the limit may matter is that the compiler decides
> to use synchronous compilation instead of asynchronous compilation.
> However, why would the compiler do that?
> * Because synchronous compilation provides benefits? What would these
> benefits be? The WebAssembly module already gets downloaded asynchronously,
> so continuing with synchronous compilation has no advantage to asynchronous
> compilation.
> * By accident, because the compiler writer does not know better? I
> think it's unlikely that a compiler writer would choose to use synchronous
> compilation by accident, and that this compiler is then used to produce a
> WebAssembly module with 10s of MB, and that the resulting WebAssembly
> module is then used in any reasonable webpage.
> * The limit would not make a difference for the following reason: On the
> website you cite above the average network bandwidth is 9Mbps. Even
> compressed the 80MB module in my measurements would take 10s of seconds to
> download. Does blocking the main thread of less than 1 second really matter
> to the user after they waited many times as long for the download?
>
> As I wrote before, I understand why this limit was introduced originally.
> However, these reasons don't exist anymore, and all that remains is a spec
> violation, see https://webassembly.github.io/spec/js-api/index.html#limits.
> Even a limit of 10MB is still a spec violation, and as I wrote before, I
> don't see any justification for that.
>
> Cheers, Andreas
>
> On Thu, Apr 20, 2023 at 8:58 PM Alex Russell 
> wrote:
>
>> Thanks for the document, Andreas.
>>
>> The numbers in it are still hugely concerning, and I'm a -1 until and
>> unless we have data from P75-P90 Androids and Windows devices. Our
>> telemetry from Edge shows that nearly half of users are on slow, spinning
>> rust and 2-4 core devices, and the only system in your test list that
>> reflects something in this range is the N2840 in the HP Chromebook 13 G1.
>>
>> Motivations in the document regarding testing are not compelling. Folks
>> doing testing can provide flags to the browser (which you could expose to
>> raise the limit without an Intent).
>>
>> Would you be willing to accept a higher cap? Your document suggests that
>> ~10MiB (unzipped) might be reasonable, but would want to see data from
>> low-end Android before going even that far.
>>
>> Thanks.
>>
>> On Thursday, April 20, 2023 at 4:06:30 AM UTC-7 Yoav Weiss wrote:
>>
>>> LGTM2
>>>
>>> Thanks for testing this! :)
>>>
>>> On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas  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 
 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
> 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

Hi Alex,

I will try to organize a low-end device to do the measurements you are
asking for. Could you please describe how the results would guide your
decision on this issue?

I would also ask you to clarify your concerns. What are the scenarios you
have in mind, and what are the improvements a user would get from this
limit?

When I think of concrete scenarios, then I end up either with the scenario
being unlikely, or that the limit would not make a big difference for the
user experience:
* Unlikely, because it is hard to end up with a big WebAssembly module that
you compile synchronously. You don't write WebAssembly modules by hand, you
generate them with a compiler like Emscripten. The compiler typically does
not only generate the WebAssembly module for you, it also generates the
code for you that downloads and compiles the WebAssembly module. A scenario
where the limit may matter is that the compiler decides to use synchronous
compilation instead of asynchronous compilation. However, why would the
compiler do that?
* Because synchronous compilation provides benefits? What would these
benefits be? The WebAssembly module already gets downloaded asynchronously,
so continuing with synchronous compilation has no advantage to asynchronous
compilation.
* By accident, because the compiler writer does not know better? I
think it's unlikely that a compiler writer would choose to use synchronous
compilation by accident, and that this compiler is then used to produce a
WebAssembly module with 10s of MB, and that the resulting WebAssembly
module is then used in any reasonable webpage.
* The limit would not make a difference for the following reason: On the
website you cite above the average network bandwidth is 9Mbps. Even
compressed the 80MB module in my measurements would take 10s of seconds to
download. Does blocking the main thread of less than 1 second really matter
to the user after they waited many times as long for the download?

As I wrote before, I understand why this limit was introduced originally.
However, these reasons don't exist anymore, and all that remains is a spec
violation, see https://webassembly.github.io/spec/js-api/index.html#limits.
Even a limit of 10MB is still a spec violation, and as I wrote before, I
don't see any justification for that.

Cheers, Andreas

On Thu, Apr 20, 2023 at 8:58 PM Alex Russell 
wrote:

> Thanks for the document, Andreas.
>
> The numbers in it are still hugely concerning, and I'm a -1 until and
> unless we have data from P75-P90 Androids and Windows devices. Our
> telemetry from Edge shows that nearly half of users are on slow, spinning
> rust and 2-4 core devices, and the only system in your test list that
> reflects something in this range is the N2840 in the HP Chromebook 13 G1.
>
> Motivations in the document regarding testing are not compelling. Folks
> doing testing can provide flags to the browser (which you could expose to
> raise the limit without an Intent).
>
> Would you be willing to accept a higher cap? Your document suggests that
> ~10MiB (unzipped) might be reasonable, but would want to see data from
> low-end Android before going even that far.
>
> Thanks.
>
> On Thursday, April 20, 2023 at 4:06:30 AM UTC-7 Yoav Weiss wrote:
>
>> LGTM2
>>
>> Thanks for testing this! :)
>>
>> On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas  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 
>>> 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 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Alex Russell]

Thanks for the document, Andreas.

The numbers in it are still hugely concerning, and I'm a -1 until and 
unless we have data from P75-P90 Androids and Windows devices. Our 
telemetry from Edge shows that nearly half of users are on slow, spinning 
rust and 2-4 core devices, and the only system in your test list that 
reflects something in this range is the N2840 in the HP Chromebook 13 G1.

Motivations in the document regarding testing are not compelling. Folks 
doing testing can provide flags to the browser (which you could expose to 
raise the limit without an Intent).

Would you be willing to accept a higher cap? Your document suggests that 
~10MiB (unzipped) might be reasonable, but would want to see data from 
low-end Android before going even that far.

Thanks.

On Thursday, April 20, 2023 at 4:06:30 AM UTC-7 Yoav Weiss wrote:

> LGTM2
>
> Thanks for testing this! :)
>
> On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas  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  
>> 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 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Yoav Weiss]

LGTM2

Thanks for testing this! :)

On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas  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 
> 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 
>>> 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 
> 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.:
>>
>> 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

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

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Philip Jägenstedt]

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

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

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

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Ian Kilpatrick]

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

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

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

 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
 
 ?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 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Alex Russell]

"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  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 
>>> 
>>>
>>> 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 
>>> 
>>> ?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 
>>> .
>>>
>>> -- 
>>>
>>> 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 
>>> 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

['Andreas Haas' via blink-dev]

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

-- 

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 

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Yoav Weiss]

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

-- 
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/CAL5BFfXvMbAiiBuF1MLx7Yf9u8kSRVo%3DO8QdpP9HBjC7D%3DFRzQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Daniel Bratell]

LGTM1

This doesn't show up in our chromestatus UI. Have you sent if for 
"shipping" there? If no further comments arrive, it may be that it has 
fallen off our radar because of that.


/Daniel

On 2023-04-05 15:05, 'Andreas Haas' via blink-dev wrote:



Contact emails

ah...@google.com


Explainer

None


Specification

None


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 component

Blink>JavaScript>WebAssembly 




TAG review

None


TAG review status

Not 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

?

No


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 
.


--

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 
.


--
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/378ec182-9017-2c6e-ad29-c37ac6d05f0f%40gmail.com.