New issue
Advanced search Search tips

Issue 713562 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 367276

Blocking:
issue 699838



Sign in to add a comment

Make queuing, and dispatching a load event on <style> elements faster

Project Member Reported by hayato@chromium.org, Apr 20 2017

Issue description

The context: https://crbug.com/699838 and https://crbug.com/712080

Supporting a load event on <style> elements takes much cost.

1. Regarding queuing load events,

   StyleSheetContents::CheckLoaded (x 1.5K) takes 35.1ms out of 63ms (StyleSheetContents::ProcessStyleSheet).
   Queuing a task for firing an event is not cheap.

2. Regarding firing events

   TaskQueueManager::ProcessTaskFromWorkQueue (x 1.5K) for firing a load event takes 38.7 ms.
   Part of 38.7ms is taken by:
   1. EventPath::Initialize          takes 16.6ms
   2. EventDispatcher::dispatchEvent takes  3.6ms

In total, it takes about 73ms. See also the attached picture.

 
load.png
218 KB View Download

Comment 1 by hayato@chromium.org, Apr 20 2017

Blocking: 699838

Comment 2 by hayato@chromium.org, Apr 20 2017

Random thoughts:

1. Do not fire a load event if a <style> element is in a shadow tree.

   I am suspicious that there is really a valid use case of load events on <style> elements.
   - For a <style> element in a document tree, it would be difficult to change the behavior for compatibility reasons.
   - However, for a <style> element in a shadow tree, it might be okay. We need to measure the usage.

2. It looks queuing is not cheap. How can we make it *batch* queuing, instead of queuing one by one?

3. Don't fire a load event if there is no load event listener for capture phase.

   This could save the cost of 2.1 and 2.2; about 20ms in total, hopefully.

Comment 3 by hayato@chromium.org, Apr 20 2017

Blockedon: 367276

Sign in to add a comment