Skip to content

Conversation

@AndriusA
Copy link

extends Timer with support for standard lib Duration type and measurements to relative to Instant on Clocks using Duration

Motivation:

Use of Timer is currently clunky with async code as any durations need to be manually converted to microseconds (et al)

Modifications:

Extends Timer with:

  • method to record duration since Clock.Instant on any Clock using Duration
  • methods that use static continuous/suspending clock by default with corresponding instant types
  • methods to measure duration of an async closure with provided Clock or default ContinuousClock

Result:

Additional Timer methods available for measuring async work

@AndriusA
Copy link
Author

note: need to remove Timer.record(duration: Duration) when #133 lands

@FranzBusch
Copy link
Member

@AndriusA Can you update this PR so we can start to review it?

FranzBusch added a commit that referenced this pull request Apr 22, 2024
# Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using `Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code

# Result

It is now easier to measure asynchronous code.
FranzBusch added a commit that referenced this pull request Mar 8, 2025
# Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using `Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code

# Result

It is now easier to measure asynchronous code.
FranzBusch added a commit that referenced this pull request Mar 8, 2025
# Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using `Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code

# Result

It is now easier to measure asynchronous code.
FranzBusch added a commit that referenced this pull request Mar 8, 2025
# Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using `Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code

# Result

It is now easier to measure asynchronous code.
FranzBusch added a commit that referenced this pull request Mar 10, 2025
# Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using `Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code

# Result

It is now easier to measure asynchronous code.
FranzBusch added a commit that referenced this pull request Mar 10, 2025
# Motivation

This PR supersedes #135. The goal is to make it easier to measure asynchronous code when using `Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code

# Result

It is now easier to measure asynchronous code.
FranzBusch added a commit that referenced this pull request Mar 10, 2025
# Motivation

This PR supersedes #135. The
goal is to make it easier to measure asynchronous code when using
`Metrics`.

# Modification

This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code
var nanosecondsClamped: Int64 {
let components = self.components

let secondsComponentNanos = components.seconds.multipliedReportingOverflow(by: 1_000_000_000)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this value could be guarded into a static constant since this never mutates and is being used in both secondsComponentNanos & attosCompononentNanos

Comment on lines +117 to +118
!combinedNanos.overflow
else {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
!combinedNanos.overflow
else {
!combinedNanos.overflow else {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants