Skip to content

Add performance marks and measures to the MR Diffs app

Thomas Randolph requested to merge 216943-add-performance-marks-and-measures-user-timing-api-to-mr-diffs-for-relevant-moments into master

What does this MR do?

For #216943 (closed)

Adds a series of performance marks & measurements to the Diffs app.

If the first and/or last file don't load their diffs for any reason (renamed, too large, etc.), we won't get good diff files information.

For example, if the first file is collapsed, it won't trigger the measure of how long it takes to render the first file.
If the last file is collapsed, it won't trigger the measure of how long all the files take to render.

However, for MRs where no files are collapsed, we will start to get a baseline of load times in these scenarios, and we can improve the missing edge cases later.

Approach

All of the diffs app performance marks are collected in a single location (performance.js) in an instrument (and deinstrument) method. They are registered in the Diffs app event hub at the top level of the app (app.vue).

To actually trigger the marks and measures, various locations throughout the application trigger the appropriate event, which is handled by the instrumentation method.

For some of the marks and measurements, knowing whether a diff file is either first in the list or last in the list of diff files is relevant (to know when the first file renders, and when all of the files are rendered, respectively). So the diff file is updated to accept isFirstFile and isLastFile properties, which aren't required, and default to false. If other use-cases don't pass these values, the relevant performance markers won't fire.

Why This Approach

Rather than scattering performance measurements throughout the app, we can abstract all that type of instrumentation to a single location. We can further isolate it by attaching it to the event hub, which doesn't require interfacing with any specific API (other than the generic event API), and doesn't technically need to be synchronous or blocking (although the current event hub implementation is). Because the events themselves are abstracted to constant values, the actual triggering locations can - in theory - never change even if the instrumentation implementation changes dramatically, including the names of the events or the names of the marks & measures.

Screenshots (strongly suggested)

allPerformanceMarks

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • [-] Label as security and @ mention @gitlab-com/gl-security/appsec
  • [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • [-] Security reports checked/validated by a reviewer from the AppSec team
Edited by Thomas Randolph

Merge request reports