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
>
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
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
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
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
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
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
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
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,
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
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
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
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
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
"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.:
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
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
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
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
19 matches
Mail list logo
