choojs / choojs/nanotiming

Way to report measurement by name

Open
#20 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
35
Forks
8
PR merge metrics
No merged PRs in 30d

Description

Hello!

(There is a gist covering this with examples if it is simpler: https://gist.github.com/fpapado/9163e02e6cf303d5b7bfe113ca5e964f)

I am trying to use nanotiming and abstract over the start/measure/report logic. One issue I am running into is the ordering of timers in the example:

```js
var timings = performance.getEntries()
var timing = timings[timings.length - 1]
console.log(timing.name, timing.duration) // log the last entry
performance.clearMeasures(timing.name) // be a good citizen and free after use
```

This assumes that the relevant measurement is always the last one in the result of `getEntries()`. However, if timers are overlapping, then this is no longer the case.

A way to pick a measurement by its name would then be desirable.
Looking at the documentation for perf_hooks, I see that [`getEntriesByName` is a method that's available](https://nodejs.org/api/perf_hooks.html#perf_hooks_performance_getentriesbyname_name_type).

The measurement name (name + '[' + uuid + ']') is available inside nanotiming, but does not get reported directly, for example in the callback. Changing / adding to line 34 would make this possible
```js
if (cb) cb(err, measureName) // or cb(err, name, measureName)
```

Is this something that makes sense to add? Have you had any similar issues with this or am I just missing something? Thanks in advance :)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start at line 34 where the callback is invoked, then review the example using performance.getEntries() and the perf_hooks getEntriesByName documentation. Check the gist for the intended timing flow and decide how the measurement name should be exposed through the callback; done means callers can identify the measurement without relying on entry ordering.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
performance, tooling
Issue type
Feature
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.