Hi @guohuideng2024, the TAG reviewed this and fount it much more plausible than the previous approach. The overall mechanism looks highly feasible to us.

We have some comments at a lower level regarding the API design.

1. The proposed new APIs markCondition() and measureConditional() are directly tied to long animation frames, and therefore:
   • The connection between these APIs and LoAF is not clear from the names and may be confusing
   • This is not extendable to use cases like, e.g., we want to analyze long tasks instead of long animation frames, or if there are new types of performance incidents we want to introduce in the future
2. We are also unsure why we need to introduce "conditional" marks and measures, instead of somehow allowing existing marks and measures to be attributed to LoAF and similar incidents.

Hi @guohuideng2024 - did you or the group have any response to the TAG's comments?

cc: @noamr

Apologies for the late reply!

1. "long task" is monitored/reported by LoAF. A single long task is sufficient to emit a LoAF. Therefore, after this feature is implemented the conditional user timing can analyze long tasks.

2. Our intention is that "conditional user timing" is not only tied to LoAF(Long animation frame), but a collection of Performance reporting API. "LoAF" is the very first Performance reporting API that monitors and includes these user timing points. Thus, we use a very general word "conditional". And we do intend to expand this to other user cases, like EventTiming or even ElementTiming in the near future.

3. We use a new name/API like markConditional instead of expanding the existing performance.mark, based on a number of considerations.

   a) They behavior very different from regular performance.mark/measure: There is no overlap between where regular mark/measure can appear and where these conditional user timing can appear; conditional user timing points and regular user timing points never interact each other(both interact within the same kind); the conditional user points (after the future expansion) operates in parallel in a number of different timelines; even the implementation of conditional user timing has very little overlap of that for user timing.

   So, conditional user timing is a completely new breed of user timing, unlike anything that existed before.

   b) We want the app developers to be able to deploy more such user timing points, so the user timing points must be lightweight, with minimal performance overhead. Unfortunately, the existing performance.mark/measure has a so large collection of functionalities built in, that operations on them cost too much CPU and memory (for example, sorting is required even for a performance.mark). Therefore, we explicitly want to exclude these Options in the existing Performance.mark/measure. By using a new API/name it's clear that the interface is different.

Thanks @guohuideng2024. Your reasoning for adding new functions makes sense to me. I'm still not sure whether this is the right name, and whether it will be quite the right design once you add a second Performance reporting API that monitors these user timing points.

1. Ideally function names describe what they apply to. "Conditional" doesn't indicate what the condition is. Something like "markForPerformanceIncident" might explain itself better, but you and the working group can probably come up with a more explanatory name than I can.
2. Is it possible that developers will want to say that a mark applies to LoAF but not EventTiming or vice versa? If so, you're going to need to add an options dictionary to the parameters. Once you've done that for measureConditional, you'll want to move startMark and endMark inside it.

https://w3ctag.github.io/design-principles/#prefer-dictionaries also suggests that your optional parameters should be inside an options dictionary even without the extra field to select the kind of performance incident.

https://w3ctag.github.io/design-principles/#prefer-dictionaries also suggests that your optional parameters should be inside an options dictionary even without the extra field to select the kind of performance incident.

This suggestion should not apply for calls like this that are expected to be called very eagerly, due to WebIDL dictionary<->JS overhead.

@noamr Can you give us some performance measurements that could go into such an exception in the Design Principles? How much time does it cost per call to wrap a string argument into a dictionary? How much can that be mitigated by caching the JS object? Approximately how many times/second does a function need to be called for you to think it needs the less-ergonomic signature?