1510755 - Tree Style (Lexically Scoped) Timers

Status: NEW

(Core :: JavaScript Engine, enhancement, P5)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

In order to get detailed information out of the JS engine on how different phases of main-thread work occur, I believe it would be valuable to have timer trees built. 

The basic idea of timer trees is that they automatically show how a particular node can be subdivided into child times, giving a more complete view of the evolution of a particular process.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Prototype of Tree Style (Lexical) Timers

This patch implements a timer tree system. The basic idea is the same as that
of a profiler, however, these timers have two distinct advantages.
1. They measure and report events non-probabalistically,
2. They may provide accuracy that can't be achieved with a sampling profiler

The result of this system is a tree of timers, such that you can see how
children contributed to the parent time:

   A (100s)
   | - B (50s)
   | - C (40s)
   | - | - D (30s)

In the above timer tree, note that the children do not all add up to the
parents: This is a side effect of missing time, which will naturally happen
where there has not been annotation with timers.

The current prototype annotates baseline compilation (this was chosen just for
ease and my own curiosity), and the timers get dumped during context
destruction with the environment variable

    DUMP_TIMERS=1

Improvements Required Before Landing:

- Currently the Persistent Timers leak.
- Currently using plain old new/delete, should be using a JS
  allocator.
- Handling Off Thread tasks.
- Improving Output (JSON?)

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Prototype of Tree Style (Lexical) Timers

This patch implements a timer tree system. The basic idea is the same as that
of a profiler, however, these timers have two distinct advantages.
1. They measure and report events non-probabalistically,
2. They may provide accuracy that can't be achieved with a sampling profiler

The result of this system is a tree of timers, such that you can see how
children contributed to the parent time:

   A (100s)
   | - B (50s)
   | - C (40s)
   | - | - D (30s)

In the above timer tree, note that the children do not all add up to the
parents: This is a side effect of missing time, which will naturally happen
where there has not been annotation with timers.

The current prototype annotates baseline compilation (this was chosen just for
ease and my own curiosity), and the timers get dumped during context
destruction with the environment variable

    DUMP_TIMERS=1

Improvements Required Before Landing:

- Currently the Persistent Timers leak.
- Currently using plain old new/delete, should be using a JS
  allocator.
- Handling Off Thread tasks.
- Improving Output (JSON?)

Comment 3

[Iain Ireland [:iain]]

I have been using this patch locally to investigate the performance of the new regexp engine. It's very useful! We should eventually try landing it.

One note: I get much more accurate average values by converting average_ into a double, instead of a mozilla::TimeDuration. It looks like the underlying type for time duration is integral, which loses precision on very short durations.