Comment from mmenke@ about a better approach than cl 1964533002:

If you want to be able to extract everything, I'd suggest another approach: 
When we create a throttle, add trace event with its URL, priority, and the
"client id" (Also known as the child id and route id).  Could also add the
URLRequest's net_log().source().id, if you wanted, to more easily track it. 
Then log when it starts, with similar info (Or just the net log ID, so can refer
to the earlier event), and then log when it's destroyed, and when the priority
changes.

Then, as long as tracing is started early enough, you can deduce all the active
requests when a request was created, so can figure out why it was throttle, if
it was.  Could optionally also add an entry when we choose to throttle a new
request (I'd put it in WillStartRequest, to reflect whether we actually delay
it, instead of when we decide we will defer it once it's started - these should
generally be the same, but there are other throttles in front of us, like
safebrowsing, that could make them diverge).

Compiling some comments from kinuko@ and blundell@:

kinuko@ wrote:
"If this is only for clovis but not for regular chrome:tracing could we use
slightly different category name / add some sub-category name (in addition to making it disabled by default)? E.g. loading.resource_queuing etc

Also adding heavy instrumentation code in very common production code for non-regular-tools concerns me a bit.  I'm not sure if we have other better ways to achieve it but in general it'd be great if we could isolate such changes as much as possible"

blundell@ wrote:

To address these concern, I have the following questions:

(1) Is tracing of queuing of resource loads useful beyond Clovis? If so, who's the right contact point to interact with re: the canonical way to add this tracing within the larger context of loading category tracing events (e.g., conventions for naming, etc)?

(2) If the answer to (1) is No, are there any recommended naming conventions for "bespoke" trace events?


kinuko@ replied:

My impression is that (1) could be true but it may not have immediate other customers.  Depending on how detailed will the info be having some sub-category name might make things a little more convenient, but I'd like to hear caseq@'s opinion on this one too.  (It's already marked as DISABLED_BY_DEFAULT so it might be actually just enough)

As Clovis has finished, this change is no longer needed. I've closed cl/1994943002 and it can be revisited later if needed.