This will help us determine how big of a problem the global lock actually is, and will also help us determine when we're making things better and by how much.
Created attachment 601049 [details] [diff] [review] patch I'm not tied to having 2 different telemetry entries for main thread vs. non-main thread, but I thought it might be useful to know how long we block the main thread vs other stuff on the cache thread.
Nick, why not to add the telemetry right inside nsCacheService::Lock() ?
Comment on attachment 601049 [details] [diff] [review] patch Honza, I have no good reason, and looking at the code, I realized there's at least one place outside the autolock where we do actually call nsCacheService::Lock directly, so in there is probably a better place to put the telemetry. I'll update the patch.
Created attachment 601066 [details] [diff] [review] patch OK, here's the same patch with the telemetry accumulation pushed down into nsCacheService::Lock as Honza suggested.
Attachment #601066 - Flags: review?(michal.novotny) → review+
Created attachment 601361 [details] [diff] [review] patch Update commit message w/r=michal. carry forward r+
I believe the times will be about a millisecond if even that long. I observed long times waiting only short after start when the cache warms up.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.