On Monday, March 3, 2025 at 5:35:10 PM UTC+9 Domenic Denicola wrote:

LGTM3, thanks for all the work here to meet our shipping requirements!

Can you update ChromeStatus with the new spec draft and explainer links, as 
well as the feedback from Workspace?


As well as the shipping milestone, which will be important for making sure 
it populates various documentation endpoints like the beta blog post.
 


On Saturday, March 1, 2025 at 5:03:52 AM UTC+9 Rick Byers wrote:

Thank you for the extra effort here Marja!
I agree with Mike, the "next step" is to ship it. LGTM2.

Then of course we should keep iterating and documenting how it provides 
real user & developer value. If another engine decides they want the value 
too then we can figure out what the right standardization venue is. Thank 
you for discussing it in TC39 and WebPerf WG!

Rick

On Fri, Feb 28, 2025 at 2:57 PM Mike Taylor <miketa...@chromium.org> wrote:

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_dt6SMGoxomo8mJuPqFBI
P85kUII3CgqUuqqwKWRZOc/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.

To view this discussion on the web visit https://groups.google.com/a/ch
romium.org/d/msgid/blink-dev/448934fc-6d9d-4e09-a728-64bf282
01636%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/a582222a-cf61-4bc2-abca-8081e128b014n%40chromium.org.

Reply via email to