RE: Proposal for JavaScript Timing Extension to the Performance Timeline

Simon,

The idea is to get this information when scripts are actually executed. I agree that this might not be obvious from the examples but that was what I meant.

Limiting the amount of data as well as overhead definitely makes sense. A more fine grained control mechanism would make sense here.

The general problem with timing hotspots is that you do not know beforehand where they are. Detecting them is usually part of monitoring and problem isolation. Once you know where the problem is you can also diagnose this in a development environment given that you have access to the code (not true for third party code) and you can reproduce the problem (this often also is not that easy; especially for personalized web applications)

User Timing would only work for your own code and you will have to decide beforehand what your Hotspots might. If you already knew that you would not need any monitoring and just fix them. If the problem is in Third Party code user timing is not useful at all as you cannot modify this code to add the timings. In other situations you  cannot do it because the code is developed by other parts of the organization and they do not have access to the code or are not allowed to change it.  This might not be the case for a company like Google, but believe me it is the reality for a lot of companies out there.

If you only see it from the perspective of someone who fully owns their code then I would agree, however, this is often not the case. We have lots of customers and for them this approach would not work. It is also error prone and requires higher implementation effort while make code unreadable or at least harder to read. Generally if we want to reach a wide adoption it has to be made as easy as possible. We have a direct comparison of the adoption rates of development kits and automatic instrumentation approaches. For the first it is much lower. As we are also talking about monitoring here we have to see this from the perspective of operations and not development.

It is common for most modern runtime environments like Java[1], .NET, PHP etc. to instrument code and get execution data from the runtime. JavaScript engines still lack this capability right now.  Developer tools in many cases cannot be uses as the problems are in the end users browsers. These users often do not have these tools installed and even if they would it would be hard to get in touch with them.

So do you think that it does not make any sense to collect this data in the browser or that a different approach would be more useful?

// Alois

[1] JVMTI - Java Virtual Machine Tool Interface - http://docs.oracle.com/javase/1.5.0/docs/guide/jvmti/

From: simonjam@google.com [mailto:simonjam@google.com] On Behalf Of James Simonsen
Sent: Friday, February 17, 2012 1:42 AM
To: public-web-perf@w3.org
Subject: Re: Proposal for JavaScript Timing Extension to the Performance Timeline

Is the idea to only do this when scripts are inserted into the page? That seems to be what the examples are showing. For many scripts, that'll just end up being parsing time.

In general, I'd like to limit the amount of data in the timeline. Developers should specifically ask for something to be recorded. We want to discourage developers from trying to collect mountains of debug timing data on users' machines. I think flipping one switch to get all the script data is too much for a broad-use API.

If a developer wants to time a particular hot spot on users' machines, they will be able to do that with User Timing. And if they want to see all of the script execution time, they can use developer tools.

James

On Wed, Feb 15, 2012 at 2:03 AM, Alois Reitbauer <alois.reitbauer@dynatrace.com<mailto:alois.reitbauer@dynatrace.com>> 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-javascript-timing-in-browsers/

Please provide feedback.

// Alois