Re: Proposal for JavaScript Timing Extension to the Performance Timeline

How does this relate to window.performance.now() that was discussed
previously?

On Wed, Feb 15, 2012 at 8:30 AM, Alois Reitbauer <
alois.reitbauer@dynatrace.com> wrote:

> The idea is to get the first executing function. This should be enough
> information for monitoring. If even this information cannot be provided at
> least a performance Entry object with an empty name should be created.
>
> // Alois
>
> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> Sent: Wednesday, February 15, 2012 5:16 PM
> To: public-web-perf@w3.org
> Subject: Re: Proposal for JavaScript Timing Extension to the Performance
> Timeline
>
> On 2/15/12 5:03 AM, Alois Reitbauer wrote:
> > A while ago, I submitted a list of potential future work targeted at
> > getting more insight into the runtime behavior of JavaScript heavy web
> > applications. As a first result out of these initial ideas I came up
> > with a proposal how to extend the Performance Timeline to expose
> > JavaScript execution time information.
> >
> > As formatting is limited for mailing list messages I posted a
> > formatted and easy to read version of the proposal at
> > http://blog.dynatrace.com/2012/02/15/specification-proposal-for-javasc
> > ript-timing-in-browsers/
> >
> > Please provide feedback.
>
> When this feature is enabled, what should be reported for function
> execution times in a JIT compiler which inlines functions and then does
> common subexpression elimination and constant-folding on the resulting
> code, effectively across function boundaries?
>
>
> Of course one could disable such optimizations when the timeline is on,
> but that would materially change the performance characteristics of the
> script in the cases of interest....
>
> -Boris
>
>
>
>
>