LGTM1
On 2/28/25 7:28 AM, Marja Hölttä wrote:
Hi again, all,
Update:
- I gave an info session about Explicit compile hints in TC39 in October.
- The explainer and the spec draft are now under WICG:
https://github.com/WICG/explicit-javascript-compile-hints-file-based &
https://wicg.github.io/explicit-javascript-compile-hints-file-based/
- I updated the format based on feedback from other browsers (minor
naming update, doesn't affect the functionality)
- We ran another Origin Trial with Workspace, comparing different
implementations of the feature, and decided which one we want to ship.
(However, the exact implementation can be modified without any
compatibility issues, since this is just performance tuning.)
- I proposed the feature (verbally) to the Web Perf WG in the last
meeting (Feb 26th).
- I requested the rest of the reviews (Privacy, Security, Debugging
etc.) in Chromestatus (still in progress).
- The feedback from Workspace (from the first Origin Trial) is
available at
https://docs.google.com/document/d/1_dt6SMGoxomo8mJuPqFBIP85kUII3CgqUuqqwKWRZOc/edit?usp=sharing
.
To answer what Rick asked above:
If we want to change the format, we can indeed do a transition where
we support both "old" and "new" formats for a while. A user-side
transition is possible, too: a web page can ship "old compile hints"
and "new compile hints" and old browser versions will pick up the old
one and ignore the new one, and new browser versions will do the opposite.
Could you advise us on the next steps? Thanks in advance!
On Wed, Oct 9, 2024 at 10:53 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
Thanks for sending over the WICG proposal
<https://github.com/WICG/proposals/issues/174> for this! I think
there's now enough evidence of industry interest in this. That
should enable y'all to move this to the WICG as a venue, which
would resolve the IPR concerns.
On Friday, October 4, 2024 at 4:34:16 PM UTC+2 Rick Byers wrote:
The main reason I'm personally gung-ho on shipping this is
that, as far as I can tell, it has extremely low
interoperability and compatibility risk. This is just metadata
that influences performance heuristics and (despite some risk)
all browsers tweak performance heuristics all the time without
necessarily having any public / transparent process for doing
so. Even in the case of developer-influenced heuristics like
PIFE, is there any precedent for following a standards track?
This proposal seems strictly better in that regard in terms of
plausibly becoming on a standards track someday as interest
grows, so taking a step in that direction seems like a net
positive to me. Marja, can you confirm that, should we get
feedback later for adjusting the syntax and other details, we
can easily change our implementation after shipping? Worst
case we support both old and new formats for ~2 milestones
while partners who really care about the perf wins they're
seeing update, right?
Of course I agree that if we can meet the bar now for getting
this into an IPR-protected venue, then absolutely we should. I
know we've reached out to some non-Google developers to gauge
interest and haven't yet found anyone interested in
experimenting. It's good to poke on that a little more (eg.
maybe this
<https://twitter.com/RickByers/status/1842204146687934513>
will turn up someone in the web perf community), but I don't
think we should block indefinitely on it as long as we have
evidence of clear user-benefit.
So in terms of demonstrating the benefit, Marja what data can
you share about performance improvements that you've seen from
properties who have tested this? From all our work on
performance of native applications (like Chrome), I think it
should be pretty obvious that PGO can lead to meaningful
user-observable performance wins, but I do agree that we
should be able to characterize those wins in a concrete public
setting before shipping.
Rick
On Fri, Oct 4, 2024 at 9:12 AM Mike Taylor
<miketa...@chromium.org> wrote:
On 10/4/24 1:56 AM, 'Marja Hölttä' via blink-dev wrote:
miketaylr@: It's very likely that the privacy & security
reviews will be very straightforward in comparison to the
API owners approval. This is essentially a JavaScript
feature (though, not a semantics changing one) so it
doesn't have privacy implications. Security-wise, it's
much less risky than other V8 features on average, so I
don't expect much work to be coming from that direction
either. That's why I kicked off the API owner discussion
first, since that's the most interesting one. Would it be
ok to do the privacy & security reviews only after this
discussion has converged?
We ask that everyone /request/ the various review gates
before we give OWNERs approvals - but we don't block on
the resolution of said reviews. Also, if you already have
internal reviews (which is likely true given that you've
already run an Origin Trial), you can just link to the
internal launch bug and use the Request N/A button.
What Mike said. It's better to kick off these reviews at the start
of the I2S, and API owners are unlikely to approve this without
those reviews started.
--
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
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/448934fc-6d9d-4e09-a728-64bf28201636%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/448934fc-6d9d-4e09-a728-64bf28201636%40chromium.org?utm_medium=email&utm_source=footer>.
--
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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3e14d359-cfa3-4726-bdc5-05f28994691b%40chromium.org.
