On Thu, Jan 13, 2022 at 1:41 AM Camillo Bruni <[email protected]> wrote:
> Yes ExecuteMicroSeconds is per call. > > On Thu, 13 Jan 2022 at 01:36, Scott Violet <[email protected]> wrote: > >> If I'm reading it right, ExecuteMicroSeconds is per call, not an >> aggregate. >> > Correct, this is per individual call, aggregation would have to happen > separately > > >> Additionally as a renderer be running multiple pages trying to track this >> at the v8 level wouldn't be that accurate. I'm wondering if the better >> place to track this is in blink's bindings? >> > Yes, from what I see this is correct, the histograms are aggregated per > process. > There is also the LongTask API where we accumulate the current v8 execute > <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/logging/counters-scopes.h;drc=11b5b115b432e67d5c2a572d11cebe6a81ced05e;bpv=1;bpt=1;l=176> > times (if the histogram is enabled) per isolate (not per process). > Maybe that is something to extend as well without having to add another > execution-time tracker with additional overhead? > That seems like exactly what I want! I'll investigate it a bit more. > > > Specifically in the code generation it could presumably track the times. >> Yuki, how realistic is this? >> > What do you mean by "in the code generation"? > Sorry for not being clear. I'm referring to the IDL compiler in blink that generates the c++ bindings code: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/bindings/IDLCompiler.md . -Scott > > >> >> Thanks, >> >> -Scott >> >> On Wed, Jan 12, 2022 at 4:16 PM Scott Violet <[email protected]> wrote: >> >>> Thanks for the pointer! >>> >>> I noticed the histogram has the caveat 'excluding callbacks.' What does >>> that mean in this context? >>> >>> Thanks, >>> >>> -Scott >>> >>> On Mon, Jan 10, 2022 at 1:32 AM Camillo Bruni <[email protected]> wrote: >>> >>>> Getting the detailed V8 times comes at a measurable overhead, this >>>> piggybacking on the existing V8ExecuteMicroseconds data from the persistent >>>> V8SlowHistograms trial is most likely your best option here to limit >>>> negative side effects from multiple trials slowing down the user. >>>> >>>> On Fri, 7 Jan 2022, 09:57 Leszek Swirski, <[email protected]> wrote: >>>> >>>>> +Camillo Bruni <[email protected]> >>>>> We have a V8.ExecuteMicroSeconds histogram which is enabled for 50% of >>>>> canary and dev (via the V8SlowHistograms >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:gin/gin_features.cc;l=108;drc=26479386abe0c05c9661f6d8c1412dde636d8ecb> >>>>> feature >>>>> flag). Maybe you could somehow intercept writes to this histogram before >>>>> FCP? >>>>> >>>>> On Thu, Jan 6, 2022 at 2:35 PM Yuki Shiino <[email protected]> >>>>> wrote: >>>>> >>>>>> [email protected] <[email protected]> >>>>>> >>>>>> >>>>>> 2022年1月5日(水) 9:05 Scott Violet <[email protected]>: >>>>>> >>>>>>> Ping. Any suggestions? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Scott >>>>>>> >>>>>>> On Tue, Dec 21, 2021 at 5:15 AM Yuki Shiino <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> +platform-architecture-dev <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>> 2021年12月21日(火) 9:45 Scott Violet <[email protected]>: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm interested in tracking how much time we spend in v8 prior to >>>>>>>>> fcp. Any idea if we have a metric for this? Presumably such a metric >>>>>>>>> would >>>>>>>>> involve instrumenting bindings, but I'm not positive there. >>>>>>>>> >>>>>>>> >>>>>>>> I know only about RuntimeCallStats >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/bindings/RuntimeCallStats.md> >>>>>>>> (V8 >>>>>>>> looks having the same concept maybe around here >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/logging/runtime-call-stats.h;bpv=1;bpt=1;l=570?q=RuntimeCallStats%20case:yes&ss=chromium>). >>>>>>>> However, if you're interested in measuring it in the wild, >>>>>>>> RuntimeCallStats >>>>>>>> wouldn't be a good fit. >>>>>>>> >>>>>>>> Anyone else would know a better idea? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Yuki Shiino >>>>>>>> >>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Scott >>>>>>>>> >>>>>>>> -- >>>>>> -- >>>>>> v8-dev mailing list >>>>>> [email protected] >>>>>> http://groups.google.com/group/v8-dev >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "v8-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/v8-dev/CAN0uC_TCyPxXdVGbAmh7JBR3e7UHxXYXtuW-yUpM9Q1hSbXBKQ%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/v8-dev/CAN0uC_TCyPxXdVGbAmh7JBR3e7UHxXYXtuW-yUpM9Q1hSbXBKQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> Camillo Bruni | Software Engineer, V8 | Google Germany GmbH | >>>>> Erika-Mann > Str. 33, 80636 München > > Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der Gesellschaft: > Hamburg | Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > Diese E-Mail ist vertraulich. Falls Ssie 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. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKARY_nREpjoESH0cjRL9d6ZAbBn7JF1zy%3D2aCx%3Dw0N8CTa0kQ%40mail.gmail.com.
