Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize and fix time::precise_time_ns() on macos #14216

Merged
merged 1 commit into from
May 17, 2014

Conversation

lilyball
Copy link
Contributor

Use sync::one::Once to fetch the mach_timebase_info only once when
running precise_time_ns(). This helps because mach_timebase_info() is
surprisingly inefficient. Also fix the order of operations when applying
the timebase to the mach absolute time value.

This improves the time on my machine from

test tests::bench_precise_time_ns ... bench:       157 ns/iter (+/- 4)

to

test tests::bench_precise_time_ns ... bench:        38 ns/iter (+/- 3)

and it will get even faster once #14174 lands.

@alexcrichton
Copy link
Member

r=me, but mk/crates.mk should be updated with the new dependency on sync as well

Use sync::one::Once to fetch the mach_timebase_info only once when
running precise_time_ns(). This helps because mach_timebase_info() is
surprisingly inefficient. Also fix the order of operations when applying
the timebase to the mach absolute time value.

This improves the time on my machine from

```
test tests::bench_precise_time_ns ... bench:       157 ns/iter (+/- 4)
```

to

```
test tests::bench_precise_time_ns ... bench:        38 ns/iter (+/- 3)
```

and it will get even faster once rust-lang#14174 lands.
bors added a commit that referenced this pull request May 16, 2014
…chton

Use sync::one::Once to fetch the mach_timebase_info only once when
running precise_time_ns(). This helps because mach_timebase_info() is
surprisingly inefficient. Also fix the order of operations when applying
the timebase to the mach absolute time value.

This improves the time on my machine from

```
test tests::bench_precise_time_ns ... bench:       157 ns/iter (+/- 4)
```

to

```
test tests::bench_precise_time_ns ... bench:        38 ns/iter (+/- 3)
```

and it will get even faster once #14174 lands.
@bors bors closed this May 17, 2014
@bors bors merged commit 8ef3e22 into rust-lang:master May 17, 2014
@lilyball lilyball deleted the macos_precise_time_ns branch May 17, 2014 01:06
lnicola pushed a commit to lnicola/rust that referenced this pull request Mar 13, 2023
flip1995 pushed a commit to flip1995/rust that referenced this pull request Mar 20, 2025
…t-lang#14216)

The lint for function calls was previously restricted to functions
taking exactly one argument. This was not documented.

Generalizing the lint to an arbitrary number of arguments in the
function call requires special casing some macro expansions from the
standard library. Macros such as `panic!()` or `assert_eq!()` exist
since Rust 1.0.0, but modern stdlib expand those macros into calls to
functions introduced in later Rust versions. While it is desirable to
lint code inside macros, using MSRV-incompatible functions coming from
`core` in macro expansions has been special-cased to not trigger this
lint.

Also, code coming from compiler desugaring may contain function calls
(for example, `a..=b` is now desugared into `RangeInclusive::new(a, b)`.
Those should not be linted either as the compiler is allowed to use
unstable function calls.

Fix rust-lang#14212

changelog: [`incompatible_msrv`]: lint function calls with any argument
count
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